Bolaji Ayodeji Start by making sure you're using Semantic HTML. Automated tools can often flag errors here. Things get tricky when you have complex widgets e.g tabbed UIs, autocomplete combo boxes. For such widgets, follow the WCAG prescription for expected behaviour, ARIA-attributes and keyboard interaction. Following the guidelines should be enough to provide the proper signals to assistive technologies. These tools know how to interact with these standard widgets. What should you test? See this chat for some testing considerations . Learn how to use a screen-reader and test your application with one. Tab around to see how much you can do with the keyboard. Switch users often benefit from a site that's designed to be keyboard-friendly.

A PM once asked "Segun, how long will it take to build this page if we didn't care about accessibility" . I responded "the same time it'll take to make it accessible" . I went on to deliver and the team made accessibility a product requirement.

Different approaches for different folks. Some people will be convinced by Moral Responsibility. More will be convinced by obvious business gains e.g good #a11y practices often translate to better SEO. Others are motivated by fear of litigation. No business owner wants to be sued. However, I have noticed most people who seem to not care about #a11y are just indifferent. In their minds, they're choosing between #a11y and something else that's "more important" . To make a change here, you need to demonstrate that it's not a zero-sum game. Accessibility and company/team goals aren't mutually exclusive. e.g I once told my PM that it'll take the same time for me to implement a feature accessibly as it would take to implement inaccessibly. Then, I went on to deliver. Gradually, the team accepted accessibility as a product requirement. As a teammate, the best way to seek buy-in is to show that it can be done at little or no cost.

The idea of web accessibility is to make web content available to as many people as possible irrespective of their disability status. If the content is a photograph. It's accessible to people who can see, but those who can't see still needs the information conveyed by the image. That's why we use alt text. What of video content? We have 2 points of exclusion here – vision and audio. We can use closed-captioning to complement the audio. We can also have a transcript available. It's important to note that disability is a spectrum and people fit in different parts of that spectrum.

Just like you test for performance and correctness in your products, you should test for accessibility. There are several tools for automated testing like linter plugins, CI tools and browser dev tools. These provide you with a baseline. Watch this chat on accessibility testing . We also mentioned a few things we like to test for. The holy grail for accessibility testing still remains manually testing. Also, as Obinna Ekwuno already mentioned there are tools and guidelines for building accessible products and UI elements.

A little over a year ago, I started my accessibility crusade at Andela and the developer community in Lagos. In what is probably best described as accessibility harassment, I started out doing free accessibility testing, reviews, and feedback. Every time I had to unblock someone on a problem, they got an accessibility audit. I made several twitter threads on accessibility, low-hanging fruits, and inclusive thinking. After one year of crusading, I have good news, a number of developers and designers have been won-over to the accessibility-first camp. They are not experts but they're making an effort, moving us one step closer to a world of accessible products. What I have learned. Consistency is key. Helping people achieve small victories motivates them to do more. There are different approaches to winning people over. Some will be moved by moral responsibility. Others will be moved by business value e.g good #a11y practices often translate to better SEO.

No, it doesn’t. It applies to all areas of human interaction, not just software. In the area of software accessibility however, all mainstream platforms/operating systems have a built-in accessibility framework as well as primitives for building accessible software. We can take advantage of this. To learn more about android accessibility, start here: https://developer.android.com/guide/topics/ui/accessibility . A quick google search for “[platform or OS] accessibility framework” should get you relevant resources on your preferred target.

Concerning Accessibility Testing, check out this conversation between Ademola and I. There are tools for automated accessibility testing and we should take advantage of them e.g linter plugins, CI/CD tooling. However, these should be the baseline. Manual testing is still necessary if we’re to be sure that our products are actually usable. Automated testing is great for picking low hanging fruits like missing alt tags, alt tags with the words “image” or “picture” in them but they can’t tell if the context of the image was meaningfully conveyed. Also in highly interactive UI widgets, automated testing could also be misleading. Treat them like Snapshot test – important but not final. Still TEST MANUALLY

Thanks, Bolaji. The reason accessibility hasn’t made it into most coding tutorials is because the authors of such content mostly do not have limiting disabilities, therefore it’s easy to ignore needs that do not affect them. This doesn’t mean they’re evil, it’s just human nature. We tend to focus on things that affect us. I dare say a blind web developer wouldn’t create web content that excludes screen reader users. This is why we must embrace an INCLUSIVE approach when designing/building software. It is possible to build a technically accessible product that is barely usable because it was not designed for inclusion. For example, giving every item on a website a positive tab-index makes it technically accessible to tab/switch users but not inclusive. Actually, that would be frustrating to these users because that’s not how they interact with pages. They expect to jump through a handful of focusable elements, not spend their entire day tabbing through every item on the page. Do I think this is changing? Yes, thanks to the advocacy being done by people like Jen, Tatiana, Obinna, and many other accessibility experts in the community. There’s still a long way to go but we’re seeing progress.