Computers Are Hard: accessibility with Sina Bahram
I have no interest in people thinking about accessibility. I have interest in people doing something about accessibility.
Accessibility features in software used to be mostly invisible to me. Sure, I believed they were important, but only in an abstract sense. Then my eyesight started getting worse and I found out it’s hard to enjoy yourself when you’re squinting all the time. I started paying attention to subtitle size options in movies and video games, because I needed them.
I wish I — and everyone in tech — spared more thought for accessibility before it becomes a personal issue. Because accessibility done right benefits everyone and yet it’s rarely done right. There’s still lots of games and video players that don’t offer something as simple as enlarging subtitles. And if even things like this are neglected, you can imagine the daily frustrations of people who need assistive technology to use software.
I discussed the problems tech has with accessibility with Sina Bahram, who runs Prime Access Consulting, an inclusive design firm that works with organizations to make their products more accessible. We also talked about what engineers should do for their software to be inclusive and how that’s more a question of good coding hygiene rather than some arcane technical knowledge.
Wojtek Borowicz: How do you make a product accessible? Do you have to think about it from the beginning or do you include accessibility at a certain stage of development?
Sina Bahram: That’s three questions and they have several premises built into them. We should first define what we mean by something being accessible and something being inclusive. Accessibility is often used as a catch-all term that means someone has done things necessary for people who use assistive technology to interact with their product. It’s rooted in a definition that depends upon disability. And if that is the case, it’s critical to understand there are many ways of looking at disability. Two most prominent are the medical model and the social model.
The medical model of disability says something is broken. Someone’s blind, can’t walk, can’t hear. And therefore, we try to fix that thing. And if we can’t fix it, then that person has an impairment, is disabled. The social model says: instead of putting the burden on the individual, we recognize it’s the environment that’s not inclusive. Not the individual that is disabled, it’s the environment that is disabling.
The reason I say this is because the second part of your question asked: should accessibility — and I’m gonna change that to say inclusivity — be considered at the beginning or as a discrete step in the process. The answer is both. It needs to be woven into the entire product development lifecycle, from conception until post-production and maintenance. There is no other way. This has been proven across tons of projects. Not to mention there is a huge cost implication there. It is fractions of pennies on the dollar to make things inclusive up front compared to remediating after implementation.
Should there also be specific points in the development lifecycle where accessibility could be considered more? Absolutely. There are places in QA/QC and in testing. And when making feature requests you can be explicit about accessibility. Like for a screen reader user to have access to the images on your platform. By being more accessible in this one way you become more inclusive. Accessibility is the outcome and the methodology is inclusion.
So you need to think about it from the start and also have parts of the process specifically driven by accessibility, including specifications, QA, and so on?
Yes, but not just think about it. Thinking about it doesn’t do any good other than making you feel better. I have no interest in people thinking about accessibility. I have interest in people doing something about accessibility. That means even on the conceptual design stage you are weaving it into your design directives. That means color contrast, text on top of images, making sure that if there’s a menu with hover functionality, it has a little arrow beside it to show it’s a dropdown. Things like these need to be done before even a single line of code is written.
And if you don’t do them early on, is it difficult to make an inaccessible service accessible?
Sometimes it can be a reasonable amount of effort. Other times, it can be incredibly difficult. It really depends on the product and has a lot to do with the underlying structure and the caliber of the coding. If something has been thrown together with WYSIWYG tools, automatically generated code, and very inexpensive programming labor, you will have more than just accessibility problems, but accessibility definitely tends to suffer disproportionately.
On the other hand, there are iPhone apps that are 95 percent accessible and the developers weren’t even trying. What they were doing was following good coding hygiene, best practices, and examples from Apple. I reach out to them to talk about some issues and they would write back and say:
‘I didn’t even know blind people could use my app. Of course I’m gonna fix this one thing for you. The release will be out next week.’
Conversely, there could be a situation where you didn’t think about it at all and you’re making an app like Instagram, heavily image-based. Now you have a lot of work to do not only because of the engineering effort, but also because the entire core product needs a treatment of accessibility and inclusivity.
Is it even possible to make an app like Instagram accessible to visually impaired users?
Yes, absolutely. Visual descriptions are just one consideration for users with low or no vision, but we must also consider switch-based access, color contrast, users with cognitive differences who prefer different UI layouts, etc. However, those are just accessibility considerations. To make something like Instagram inclusive, it requires promoting affordances that will make that happen. Things like crowdsourcing descriptions or allowing people to search only for images with descriptions or making sure to promote and facilitate content about persons with disabilities and workflows around generating that content. This is only a small fraction, but these actions are not just done for some small percentage of the user base. They help everyone. They do not, contrary to naive belief, make the experience worse. They also, not that this should be the only goal, enhance value and support all popular return on investment (ROI) arguments.
You said that some of the accessibility problems can stem from inappropriate tools. Are there existing tools for building accessible products or do engineers need to make them for themselves? And does the quality of tools differ between platforms?
There’s a lot of different components to be aware of here. Let’s just talk about the web. There’s tooling that results in mostly accessible stuff. If you use a vanilla instance of WordPress and you use a readable theme, chances are your website is going to be okay. Not going to be great, not going to be accessible in all the technical ways, but it will be somewhat usable because the underlying tooling supports basic structure, good semantics, and the ability for the user to go in and fill in alt text, facilitate keyboard access, and caption videos just to name a very few things. So even if there is something wrong, the system provides a facility to fix it. Whereas any type of WYSIWYG editor, like Squarespace for example, is a black box. They don’t let you go in and modify what you need to make the site accessible. And you generally end up with very, truly inaccessible code. Because of the way this tool has been designed, it’s going to map everything as a div, it’s going to nest things inside of other things, it’s just not going to be accessibility-aware. And you’re also not gonna get a lot for free. The reason is that Squarespace, even though they know about the issues, have refused to put effort into fixing them or even providing the basic functionality for the content creators on their platform to address these needs, which is so incredibly unfortunate and frustrating.
When we talk about integrated development environments (IDEs) like Visual Studio or Xcode, there are plugins and libraries that can help enhance or test for accessibility issues, whether it’s on the testing side or it’s a UI library that generates more accessible components. This is true on the web as well, for example with the latest version of Bootstrap or with components like CodeMirror. When using anything, a library or a framework, it’s very important to be aware of what is being done for developers — and of what we need to do. And if the tool doesn’t do something but at least we’re able to fix it, that’s one thing. If the tool doesn’t do anything about accessibility and prevents you from doing anything, then you have yet another circle of problems. It’s a multi-layered issue.
Would it then be correct to say that a big part of making a product accessible is choosing the right tools and following the principles of good programming?
I would flip the order of those. I would say following the best practices, using the recommendations in the specs (like the ARIA spec or the HTML 5 spec), writing compliant code… these are gonna make a huge difference. Because if you commit to those things, you will pick frameworks that support you in them. If you don’t care about code validation, then you’re not gonna care about the code validation of the framework you’re using. On the other hand, if you have a strict requirement that all code in your project must be validated, you’re just not gonna let in a module that generates crappy HTML. So I would say the order of priorities should go that way.
ARIA
Accessible Rich Internet Applications is a technical specification for making web content usable and friendly to people relying on assistive technology, like screen readers and dictation tools. ARIA is maintained by the World Wide Web Consortium (W3C) and is a widely adopted standard for web accessibility.
Is learning to build accessible products more a matter of adopting the correct mindset rather than learning specific technical skills?
Exactly. Then the technical skills help you facilitate the natural objectives that arise from such a healthy mindset. You can learn more about ARIA, you can learn more about how assistive technologies interact with your stuff, but a lot of that has to come from expert users. You need to involve expert users for that knowledge transfer, read and educate yourself on these matters, and simply do those things that any professional does to enhance and perfect their craft.
Does not having personal needs for accessible products make it more difficult for teams to design, develop, and test with accessibility in mind?
It can if the culture has not prioritized inclusion. But if it does, they don’t need accessibility needs themselves as the sole way of getting it right. It’s also important to understand you will be very hard pressed to find me a team of people who don’t have accessibility needs. A lot of times those are silent and people don’t talk about them. But 20 to 25 percent of people have some form of disability. So if you talk about any development group of a reasonable size, you’re gonna find people with those needs. And this diversity helps, of course. It’s just that they might not be as profound as for someone who is a screen reader user or for someone who needs to enlarge the text 400 percent or is profoundly deaf or hard of hearing.
We mentioned screen readers a couple of times because it’s the first thing that comes to mind when talking about accessibility. What other considerations and solutions are there?
In general, we should take a more inclusive strategy and not make assumptions about the abilities of the user. Instead of assuming we may have a blind person using this product, we should instead ask ourselves: are we relying on the use of vision to complete a task? Why are we doing that if we don’t need to? It’s a subtlety but makes a big difference, because then you don’t accidentally leave out a group you didn’t think about at the beginning.
Now, with respect to things that are not thought about as much as screen reader users and users with low and no vision. People who are deaf and hard of hearing rely on captions, transcripts, and sign language. Folks with cognitive differences will benefit from plain-language explanations of controls and non-confusing layouts. People with dexterity differences may be unable to drag a component across the screen, so providing a keyboard equivalency not only allows a screen reader user to benefit from that but also a sighted keyboard user. There are a lot of different ways and groups of people to be thinking about here.
What are some low-hanging fruits you wish developers paid more attention to?
Label your controls. The number of unlabeled buttons that screen reader users come across is frankly ridiculous. It’s just not acceptable. This is something that can be automated and should just be a best practice. When you make a button, give it a damn label. It’s not hard. That’s one thing that would go a long way.
Structure is something a lot of developers don’t think about. Heading order matters. Don’t just use a level three heading because you think it looks good. That’s what CSS is for. Headings are for conveying semantic structure. So, again, it all comes down to using technologies the way in which they were designed. Don’t use a link and style it as a button. We literally have a button tag. Use it. And when you do, you get so much for free. You don’t have to do much to make a button accessible. That’s because everything in HTML is born accessible. Lots of hard-working people spend their time making sure that’s true.
That all of a sudden alleviates this perceived burden, which you haven’t asked about but is a very commonly held myth, that this stuff is hard and intricate. It need not be. If you want to talk to me about a multi-user drag and drop scenario with a real-time requirement, okay, yes, we gotta go through some design thinking on that. But a video player, a blog, a to-do list, or a messaging app like Signal or something, that’s not hard. Those are known patterns and so many of them have been implemented by various libraries and operating systems for developers. Developers just have to use the components the way they were intended to and stop reinventing the wheel as a primary first step. It’s important to point out that developers is a catch-all term here for the development/design team.
CSS
Cascading Style Sheets is a style language for customizing the look of websites. It’s usually used in combination with HTML and JavaScript and is one the primary tools for web developers.
Should every front-end developer know these things, because it’s just proper coding?
Yes, that’s exactly right.
What are the best examples of accessible apps or websites?
Definitely Twitterrific on iOS. They’ve done so many things right. They didn’t just do bare accessibility. They tried to make the experience pleasant for a VoiceOver user, for a low vision user, for a high contrast user. They had night mode before everyone was talking about it. They had rotor actions where you can flick up and down with one finger if you’re a VoiceOver user and immediately retweet something, reply, like a tweet, or bring up your profile, all without making you go through three screens. They got it right. Twitter has, unfortunately, made API changes that have made the app less useful, because Twitter is prioritizing their ad revenue over the usability of their platform. But Twitterrific? Iconfactory are the folks who made it and massive props from me. I have nothing but respect.
WhatsApp is pretty accessible currently. It definitely has a few things that could be improved. Facebook’s web accessibility is somewhat suboptimal in my opinion but their app experiences on iOS tend to be more accessible. I’m terrified that a more ad-driven model will be used for WhatsApp in the future, though, making things less accessible. Let’s hope that doesn’t happen.
Zoom has done a reasonable job. It’s not perfect but they have definitely tried and are taking accessibility seriously. That’s why I don’t use Skype, anymore, by the way. I and others informed Microsoft about various usability and accessibility issues with Skype but to no avail. So, we moved all of our client interactions over to Zoom. With Skype, VS Code, and other offerings, I feel Microsoft talks a great deal about accessibility, but it is nowhere near the usability or accessibility I and many others expect and deserve.
Netflix has really done a good job surfacing audio description and captioning for many of their shows and movies. These days I am surprised when something doesn’t have audio description as opposed to being surprised that it does. And that speaks to a very good job on their part. And they didn’t start that way. They started with the National Association of the Deaf suing them over captions. They took it seriously and instead of going for minimum compliance or trying to fight it legally, they really upped their game and I gotta tell you, they’ve encouraged other platforms. It is my firm belief that none of the new streaming platforms would offer audio description if Netflix wasn’t doing that. They not only made their platform better, they made the entire industry better.
There’s an app called Dystopia, which is a Reddit reader. This is really important because oftentimes people with disabilities are excluded from popular platforms and emerging technologies. Reddit is by no means an emerging technology, it’s been around forever, but believe it or not: there hasn’t been an accessible Reddit mobile client until about a few months ago. My understanding is that it’s just this one guy who is still at school and just wanted to make Reddit accessible. And it’s night and day. He has truly taken feedback and, like the Twitterrific way of doing things, tried to make the experience not only fully accessible, but went well above and beyond to make it fully inclusive. And not at the expense of any other group.
This last point is key. I have no interest in something that is very accessible but is not pleasant to look at or to hear. It needs to be good for everybody. I want to be really clear about this. Inclusive design is beautiful design, which happens to also be usable by as many people as possible.
Computers Are Hard
- Introduction
- Bugs and incidents with Charity Majors
- Networking with Rita Kozlov
- Hardware with Greg Kroah-Hartman
- Security and cryptography with Anastasiia Voitova
- App performance with Jeff Fritz
- Accessibility with Sina Bahram
- Representing alphabets with Bianca Berning
- Building software with David Heinemeier Hansson
