While web accessibility usually carries a specific meaning (accessibility given certain disabilities), I typically think of it in the true sense of the word; making software accessible to as many people, user agents, devices, and machines as possible. To me, accessibility is a design problem that needs to be solved. A problem that isn’t separate from the rest of any application’s architecture. A problem that needs to be approached properly, and planned for thoroughly.
Unfortunately, the reality in which we approach accessibility is a little bit different. I was stumped by one of my colleagues who asked me:
“I hear you talk constantly about accessibility, but man, it’s such a boring topic. Do you really dig it?”
The answer is obvious … I’m blogging about it. So, yes, I dig it. But what was most interesting about his statement is that I actually agreed with him. Let me explain. My colleague’s statement made me realize how poorly, us, web developers approach accessibility. It is, unfortunately, thought of as a task or checklist that gets tacked on at the end to be “compliant” or to fulfill some requirement. How can this not be boring?
But it’s not more boring than writing your unit tests after you’ve implemented your functionality, whatever it might be. It is the same concept. Test driven development (TDD) is fun when you follow its principles; letting your tests guide your design and development of better code. If you do it last, then you’re just fulfilling some “silly” requirement while not reaping the benefit of the approach.
Accessible web applications are not happy accidents. They are a direct result of good engineering principles and solid design put together. They’re based on deliberate and intentional design. So, to produce quality, accessible web apps, we need to change our perspective.
How do we do that? How do we become more empathetic to users with disabilities? I’m glad you asked.
“You don’t need to change peoples’ mind about disabilities, you need to change their minds about themselves.” – Music within.
I love this quote from the movie music within. It reframes the approach to promoting better accessibility practices. We need to start changing the way we think and develop web applications. We need to approach the problem a bit differently. Here are some thoughts:
- Content-first Design: Understanding the content, it’s priority in the document, the relationship of this content to other companion content, and the grouping of content to form meaningful objects is content design. Additionally, being aware of the various medium and workflows the content might be consumed is important to understanding how your content might be tailored and delivered to varying audiences. For more info on the topic, watch this presentation on how content-first design workshops might be conducted.
Beginning of development:
- Progressive enhancement: Starting really simple is the key to having a maintainable and logical web application. For instance, rather than laying out the styles while developing the page, write the flat markup first and see if it makes sense. Progressive enhancement suggests starting from simplicity and then layering in enhancements for more capable user agents.
- Semantic markup: divs have no semantic meaning. There might be some other tags that provide better semantics. For instance, use the html5 header tag for grouping outlined headings or for your site’s header. Use the section tag for logical sections in your page. Here is a link to an HTML5 element flowchart.
- ARIA roles: ARIA – Accessible Rich Internet Applications is a spec that helps provide better context to screen readers of rich web apps. ARIA uses landmark roles to describe certain portions of the page. For instance, developers can specify that a header tag is used as a “banner” using ARIA role=“banner.” This aids non-sighted users in quickly understanding the context of the section and, hence, the layout of the page.
- ARIA roles also have other atomic values for widgets such as sliders, toolbars, menus and menu items. These are helpful when writing a UI framework.
- Test your application using a variety of different tools. There is a bunch of automated accessibility tools out there that can help.
- Juicy Studio Accessibility Toolbar.
- Finally, put your site to the test. Learn how to use VoiceOver (a screen reader software) if you’re on a Mac or the Accessibility mode if you’re on Windows. There is also a Chrome screen reader plugin by Google called ChromeVox.
- Last but not least, test the usability of your web application with non-sighted users if at all possible.
I hope to elaborate on the different approaches listed above in future posts. I just wanted to put some thoughts out there to, hopefully, get others thinking about the topic.