Let's Talk
Recently Fusionbox had the opportunity to visit a part of CU Denver called the Assistive Technologies Lab, where we got to talk to clinicians and engineers whose primary job was to study how technology could assist individuals with varying levels of disability live better lives.
These amazing people showed us many aspects of assistive technologies that I had never considered before. We saw tablets running software to help people with developmental disabilities related to speech that would help them form sentences and communicate with others. We also got the chance to see someone getting their very first electric wheelchair and the custom fit process involved in shaping the wheelchair to his unique body shape.
All of this was very eye-opening in terms of how far technology has come in order to help all people enjoy as high a quality of life as possible, but it's also clear how far we have yet to go.
Fusionbox wants to do its part to make the web accessible, and so we sat down Cathy Bodine, and Jim Sandstrum to discuss common accessibility problems for people with disabilities on the web, and we came up with a short list of the most important things to test if you want your web application or service to be accessible to as many people as possible.
Test with screen readers
One of the most impacted groups of people, in terms of interacting with computers and the Web at large is the blind and visually disabled community. These people use an assistive technology called a screen reader to read the contents of their screen to them. While there are standards regarding building applications and websites with maximum compatibility with screen readers, we learned that not all screen readers implement the standard in the same way. That means an application that is compatible with one screen reader may not work entirely correctly with another screen reader. Furthermore, changes and regressions can happen between individual versions of a specific screen reader!
Jim, who does accessibility consulting, recommended testing an application with multiple screen readers as a sanity test, but more importantly programming to the specification. Screen readers will have specific implementations of that specification which can change between releases, but the specification is much less likely to change.
Organize your HTML
A surprising number of accessibility issues can be solved simply by applying best practices to the structure of a web page. If the visual order of the page matches closely with the DOM order, the browser and screen reader will handle a lot of the work for you.
For example, reading order is the order in which a screen reader will read the screen out loud to its user, but screen reader users won't usually sit and listen to the screen reader read the entire page for them; they will navigate through document headings and sections seeking the content they're interested in. If the web page's DOM is structured in a way that mirrors the content, this becomes relatively easy.
Another important accessibility attribute of a website--for all your users, not just disabled ones-- is tab order. The tab order of a website is derived directly from the DOM and, again, should ideally match the visual order of the document. This allows users that prefer to navigate the site with a keyboard, whether they have a disability that limits them to the keyboard or if they just prefer it.
Keyboard Accessibility
Closely related to tab order is keyboard accessibility in general. The more standard keyboard navigation your website supports, the more accessible it would be. In general, the browser can handle most of these keyboard controls for you. But if, for example, you're implementing your own date picker, take some time and read the WAI-ARIA standards for date picker keyboard controls.
Test Zoom Levels
Not all visually impaired people are blind. Some need screen magnification in order to interact with computers. Have you ever seen your site at 300% magnification? Chances are, it doesn't look pretty, but the real issues happen when elements don't re-flow and instead fall off the screen. Where did that submit button go?
Don't fall down the rabbit hole
Automated accessibility tools will yell at you and generate a lot of false positives for a lot of things that are sometimes inconsequential. "Not all of your images have alt-text!" Well, the images that are important parts of the content or the layout probably should have alt-text, but it's probably OK if the less significant images are missing it.
If you have the time to read through the accessibility report and decide which issues really require attention and which are just noise it's probably worth it, but it's definitely not the be-all-end-all. The issues outlined in the previous sections might not show up in an accessibility report, but they will almost certainly make a bigger impact than adding alt-text to every single one of your site's images.
Going further
These tips can help you greatly increase accessibility on your website, but it doesn't take care of everyone. There are users with cognitive disabilities that may not be able to navigate your site or service. There may be users with motor disabilities that have trouble interacting with your widgets. If this is an audience you expect or that you wish to cater to, the best thing to do is to conduct a usability study and address the issues brought up in it. A usability study requires experts like the ones found at the Assistive Technologies Lab, who have done many such studies, so get in touch with them for help setting that up!
And, if you need accessible custom Python Development, we'd love to talk about your project!