ELI: Yeah, so I'm Eli, my pronouns are he/him and they/them, and for anyone who can't see me well: I'm a white, fairly deliberately androgynous man, I'm wearing a bright purple shirt that says "Accessible, equal web access for all," and I work at The Carpentries, and I'm talking about "The Other Kind of Accessible," which is about removing software barriers for disabled researchers and RSEs.

So I'll talk a bit more about what I mean by this other kind of accessible, and what I mean when I'm talking about disability and barriers. Then, why you should care about this and what you can do.

So I've been an RSE for about five years - I'm currently working at The Carpentries as an IT developer. I'm also a Fellow of the Software Sustainability Institute, and they funded most of the learning that I've done on this subject and me being here to give this talk as well so thanks SSI!

I also use voice control and eye tracking software because I have chronic RSI that affects my hands. And as I tried to get my particular setup working I realized how much harder it can be to use the web with assistive technologies like these. Then I started studying disability and accessibility, and it's culminated in me being here to give this talk. 

My motivation for this talk specifically is that I've ended up kind of straddling two worlds. There's the RSE world and there's the web accessibility world...which mostly exists in industry. And the word accessible gets thrown around a lot in both, but it tends to mean quite different things in each context.

Sometimes I see talks or discussions or just general chat about things like quote "software ergonomics" or quote "software usability" in RSE space, and these tread the same kind of ground as I'm going to talk about, but they rarely mention disability specifically.

I want to bring disability back into these conversations. It's disability activists that started a lot of this work off in the very beginning and sometimes it gets overlooked. There's also a lot of accessibility expertise in industry that we in the RSE community can definitely learn from so I want to bring your attention to all of that as well.

So, what do I mean when I'm talking about the other kind of accessible? I kind of already spoiled it in the talk title...but first I want to talk about what accessible is described as in the FAIR for research software specifically, the FAIR principles. This states that software and its metadata is retrievable, or should be retrievable, by- via standardised protocols, so protocols that are open, free, allow authentication and so on. This doesn't mention disability anywhere. What I'm trying to talk about with this other kind of accessible is accessible in the disability context. So accessibility means that disabled people can do what they need to do in a similar amount of time and effort as someone that does not have a disability. It means that people are empowered, can be independent, and will not be frustrated by something that is poorly designed or implemented.

The A in FAIR doesn't really cover this... I read through the other- the F, the I, and the R, and you could maybe argue that it's slightly covered in some of those but it's not really explicit anywhere and I think this is a bit of an oversight. I don't know how to fix it but I want to talk about it.

To make it a bit clear what I'm talking about in the context of accessibility in a disability context, I'm going to introduce the term "a11y". This is a shorthand that's used a lot in industry for this digital accessibility. It's like- it's a numeronym so it's like an acronym but it has numbers in it. And it comes about because there are 11 letters between the A and the Y in the word "accessibility." I tend to pronounce this "ah-lee" some people say "A-eleven-Y". In this talk I'll probably just say accessibility as a whole word...

And to understand what I want to talk about with accessibility we first have to understand what I'm talking about when I talk about disability and barriers. So a little crash course on that as well... In particular I want to talk about two models of disability. These are ways that you can think about disability...the first one being the medical model. So under the medical model of disability, disability is the result of an impairment. Any treatment is focused on kind of fixing, maybe curing the disability, or providing special individual services, so quote "special schools" or specific patient transport schemes. And the disabled individual is typically expected to take the responsibility for adjusting to their disability, so they make their own accommodations and adaptations so that they can do certain things.

A statement you might hear under this model would be something like "she can't read the newspaper because she is blind." And this model is quite prevalent in society at the moment, but I want to present a model that runs pretty much counter to this which is the social model of disability. 

Under this model, disability is not intrinsic to a person, but it's the result of barriers in society, so it's separate to any impairment you might have. And this means that a person may be more disabled by some environments than others...and it's everyone's responsibility, it's society's responsibility, to remove these barriers that are disabling people. So a statement that you might hear under the social model is quote "she can't read the newspaper because it's not published in large text or Braille." This puts the responsibility onto the publisher for not publishing in an accessible format, rather than- rather than blaming a person for their impairment. 

For this reason, the social model is broadly preferred by the disabled community, and it is also why I'm using the term "disabled people" rather than "people with disabilities," because you are disabled by things beyond you, and it's not necessarily something that's intrinsic to a person.

So, I want you to ask yourself throughout the rest of this talk: what barriers exist within my software or my projects that I could remove or at least start to work on removing?

And here's a deliberately long list, running off my slide, of potential barriers that we can create, deliberately or indeliberately, in some of the work that we do. I'm not going to go into explanations of why all of these can create barriers, if there are specific ones that you want clarification on or an explanation of please ask in the Slido, and we can come to them at the end. But I'm just going to read them out and I guess clap in between for separation... so text formatting, color, size and font [clap] screen reader incompatibility [clap] lack of captions or transcripts on videos [clap] buttons that are small- buttons or controls that are that are small and hard to click [clap] controls that don't support both keyboard and mouse input, they only require one or the other [clap] complex page layout [clap] complex text [clap] animations, especially moving, flickering, or blinking content which can be a seizure trigger [clap] lack of instruction in the form of tutorials or documentation [clap] lack of support whether synchronous or asynchronous [clap] inaccessible events [clap] and so on. This is not an exhaustive list, I couldn't give you an exhaustive list and I don't think you'd want me to. But this is just some examples to think about. 

I also want to talk about an example study that I came across that studied Jupyter notebooks specifically. So these are an increasingly common way of publishing a particular piece of research, and in a study of 100,000 randomly chosen Jupiter notebooks, about half of them start with a heading in the first cell. So headings are really useful as landmarks for anyone to get around a notebook, but especially screen reader users navigate a lot using heading landmarks. So about half of them start with a heading, which is fairly good but could be a lot better.

4.5% of notebooks, where they had a chart, also included a data table. Including data tables is useful for people who cannot see or interpret your chart. And this is generally a fairly easy thing to include but a lot of people don't think to do it, but it's an easy win. And then, I think the worst statistic I found in this paper was that of all the images that existed in these 100,000 notebooks, 0.19% of them had alt text on them. So alternative text is a text description of the image, you can attach it to images, and where the images did have alt text, most of those were just "image" or "PNG" or "alt," which doesn't give you any indication of what's actually in the image, so the amount of useful alt text is is even smaller.

And this study also found some systemic issues, so for example, matplotlib doesn't support embedding alt text into image files, so you have to do it at the point where you're including an image in Markdown for example, rather than being able to do it directly through the matplotlib Python interface. Also the Jupyter default themes if you're exporting a notebook to HTML, they don't meet accessibility guidelines, so they end up with contrast issues and other accessibility issues.

So there's- there's work to do at every level really.

And my next section is "why should I care?" Hopefully if you're here you at least care a little bit! 

But a common response when we start talking about accessibility is "well, I don't have disabled users! My software does not have disabled users." My first response to that would be: are you sure? They are unlikely to tell you, some people do not disclose disabilities, and especially if you have a large user base there's pretty much no way to be sure. Even if you have a very very small base of users, maybe it's just you and you know that you aren't disabled, but are you sure that you will never have disabled users? Can you be sure that nobody that ever comes to work on your project, nobody that ever wants to contribute to your project, will ever have a disability that you might have put in a barrier that prevents them from doing so? 

And similarly, are disabled who want to be- people who want to be your users turned away at the point of entry, like they don't even make it in, because your software is inaccessible to them to begin with. You might think that they would tell you when this happens. They won't! They will just leave and they'll go and find another software or they'll write their own thing or they will just leave academia entirely, which is... brings me onto my chart which illustrates the problems that we have in academia with disability representation.

I've got a line at the top which shows the general population as of the 2021 census with- known to have a disability, and that's at about 18%. So as of the 2021-22 academic year, the undergraduate representation was about equal to that general population, but then as soon as you hit postgraduate students, it drops to about 11%. Once you get beyond postgraduate to various different contracts you get down to about 7%, and then once you hit professors, the representation of disabled professors is about 3.5 to 4%, I can't remember what the exact number this is on the graph. So we've got- we're losing disabled people from the academic community at every stage of their career, and by not caring about accessibility in our projects and in our software, we're contributing directly to this problem.

And this is a data table that's ended up formatted slightly weird that has the same data in it.

Also it's the law, I'm going to kind of gloss over this slide for time, but there's the UK Equality Act which applies to everyone, and there's also a specific piece of legislation for public sector bodies that I'm not sure if it applies to public sector funded projects or just things like national labs, but some people here may have to consider this too.

So hopefully, I've persuaded you that you should care about this, and you're now asking yourself, well what can I do, what steps can I take to try and improve my own projects? I'm going to make a bunch of suggestions for people at different levels within a project, and I want to be clear that you don't have to do all these things at once, it's quite overwhelming to try and do all these things at once! Please pick one thing that resonates with you and try to focus on that first, and you can always come back and do more later.

Also, a lot of the resources that I've shared, I've linked lots of things in these slides, a lot of them are focused on web development because that's where the most interest is in industry from what I've encountered, but there are parts of these lessons that apply to every project whether they're web projects, GUIs, CLIs or something else that I have not thought about.

So supposing you are a developer on a project, there are some basic checks that you can do with just what you have at the moment, you don't need to install any particular software. So you can try completing tasks, maybe a particular workflow, a common workflow in your software, with- try it with only the keyboard or only the mouse. So if you've got a command line interface this may be straightforward, because they're keyboard only to begin with, but in web interfaces and GUIs there's- this can be trickier.

Try different visual settings, so try zooming the whole interface to 200% and seeing if things get a bit weird! It's quite common for elements to start overlapping each other or vanish or just behave in really strange ways at high zoom, but this is a really commonly used adaptation that some people use. Most computers also come with a high contrast mode, at least Windows and Mac definitely do and I think they exist for Linux...and again this kind of...this might invert the colors in your interface or it might make them- it might change them in some way to make them stand out more, and again you might find some things sort of disappear when you do that. You can also apply colour filters to simulate certain forms of color blindness or turn your screen completely greyscale, which again can illustrate some issues with colour.

And on that theme, check your use of colour. There are really clear guidelines online around sufficient contrast between text and a background and what colors are suitable. And if you are using colour to communicate something try to also include something else that communicates the same thing, so if you have a blue link, also underline the link, so blue isn't the only thing that indicates that it is a link.

And if you are developing a web interface there are automated testing tools such as WAVE which can run a scan on your page and tell you what issues there are with it, and they don't cover everything but they're a good place to start. Or if you want to do a deep dive and learn a bunch of things, there are a bunch of checklists that exist. You can pick one and follow one of those.

If you create content in the form of papers, blog posts, videos, talks...again check your use of color, check the contrast of your colors and so on like I mentioned before. Ensure any non-decorative images that you're using, which is most images in scientific contexts, check that they have alt text, this is a really easy one to do. If you have complex images such as charts, graphs, or maps, provide a text alternative or a data table alongside them like I did earlier in this talk.

If you generate videos, please ensure they have human generated captions and/or transcripts. AI generated captions, I think most of us have encountered them and most of us have realized that they are not very good. Human- human generated captions are the way to go at the moment.

Remember that headings and tables are useful landmarks for lots of people to get around in a particular page, and use them liberally but not- maybe not too liberally! But use them, you know, whenever it's useful.

If you're at a slightly higher level and you're able to guide the direction of a project- and these aren't like mutually exclusive things that you can be, you might be both a project lead and a developer on a project...but if you do guide project direction, consider setting accessibility requirements and targets for development. You can use automated accessibility tests in your continuous integration if you use that. We use a tool called pa11y which is free and open source, and that again just scans all our web pages and gives that automated report on all of them. Try to prioritize accessibility in your planning or roadmapping process if you have one. And crucially, treat accessibility issues as bugs. These- these can have varying levels of severity and treat them as severe when they are...when they're blocking people from from using your software at all.

Try to arrange user testing that includes disabled users specifically... or- and/or a professional accessibility audit. There's a lot to know about accessibility and it's hard to learn it all, but there are people out there who know much of it and can test your software for you. And ask: are there barriers in the development process that would prevent some people from contributing? And if there are then try to work on that.

If you have enough influence to guide organizational direction, again set accessibility requirements and targets for projects or ask your organization to do. Invest in accessibility training for developers. Consider following an accessibility playbook or using a maturity model to guide accessibility L&D in in the long term.

Finally if you influence funding bodies, please push for accessibility to be prioritized in all research outputs, including but not limited to software. And ask them to reward grant applications that describe how they will consider and design for disabled users during the project.

If you want to learn more, there's a really active Slack workspace that I can invite you to if you want, if you ping me on the RSE Slack. This is a community of practice with thousands of practitioners, from beginner to expert. And then there are self-study courses, collections of resources...and I've just set up on the UK RSE Slack an #a11y channel so A-eleven-Y, if you'd like to join that, and maybe we can set something up together to talk more about this. 

Thank you everyone! You can email me or find me on Slack. I don't tweet or toot or any of those things, but you can chat to me while- while I'm here at RSECon too if you're here in person. And there's a link to these very slides at the bottom here. Thank you.

JULIAN: The first question is what should you write for an alternative text for visualizations and plots, are there other ways of making visual- visualizations accessible?

ELI: Yeah, this is a difficult question. It depends! If you've got a really complex visualization then trying to describe everything that's going on within it can be difficult. As I mentioned if it's something like a chart where you can offer a data table instead, tables are really much easier for screen reader users to navigate for example, so those are a good option. Generally, try to be descriptive not just about, like, what the specific shapes on the visualization are doing, but try to also explain what you're expecting the viewer to infer from your plot,if you're not already explaining that in text elsewhere. There are people working on making accessible visualizations that can be interacted with with screen readers, I'm not an expert on that but again in that web-a11y Slack that I mentioned there are people who work on that sort of thing, and I can send you an invite if you ping me.

JULIAN: Thank you. The next question: there might be incompatible concerns in general but explicitly within accessibility, for example underlining or color highlighting as you said might then challenge people with dyslexia. How would I tackle such? 

ELI: Yeah, so...let's see...there are quite a lot of common practices, so like underlining links for example and making them blue is a very common practice across the web. It is possible on the web specifically for people to add their own stylesheets, like make- set up custom stylesheets that change the fonts or specific CSS on a web page so that it's more readable to them specifically. So that's part of it. There are Web Content Accessibility Guidelines, it's this huge document with loads of discussion on exactly this sort of thing, and it's- they're very specific about what's- what the best practices are and how to try and make things that are accessible for as many people as possible. The reality is that nothing is ever going to be accessible for absolutely everyone, we're just trying to maximize in general. 

JULIAN: Okay, thank you, we'll take one last question. There is a phrase "a picture is a thousand words" and you may be familiar with the animation of a dinosaur having the same mean and variance as a circle. [laughter] I'm personally not but you might be! How useful are data tables for non-trivial data?

ELI: I also haven't seen this animation but I would like to! [laughter] 

JULIAN: Someone please put a link in the RSECon channel...

ELI: Yeah, this is one of those questions where it depends. If you have a data table that's got, you know, 100 columns and 2,000 rows, that's not going to be easy to navigate, so it it's a question of like how much data that you have, but also...some visualizations just are too complex, and if you're struggling to think about how to represent this in a way that's not visual, maybe there are ways that you can reconsider how to simplify the visual data that you're showing as well.

JULIAN: Okay, then let's thank the speaker again.