As a web developer, one of the biggest sources of frustration is developing a website that works across the wide array of user agents and operating systems the visitor may be using. The web standards movement was supposed to “fix” that. It did make good progress and then CSS3, HTML5, and HTML5 multimedia and mobile devices sort of tripped that up. Luckily there are people out there creating tools and techniques to help us keep up and find workarounds for things like spotty support for new features. This reduces frustration somewhat. That is, until you add accessibility into the mix. Then you have to add assistive technologies onto your list of concerns. In addition to understanding the various differences in browser support for CSS properties, HTML elements, and DOM methods/ properties, you now have to concern yourself with the differences between types, brands, and versions of different assistive technologies. Like browser vendors, assistive technology vendors each have their own direction, their own goals and plans that may not agree with other vendors of similar products. Like browser vendors, assistive technology software also sometimes have bugs and missing or incomplete features. Like browsers, developers must make an informed and rational decision regarding which assistive technologies, brands, and versions they plan on supporting. Just as you shouldn’t be expected to support all versions of all browsers on all operating systems, you also shouldn’t be expected to support all versions of all assistive technologies on all operating systems.
None of this would be necessary if everyone just followed standards. Sadly that’s no more the case for assistive technologies than it is for browsers. I was reminded of this today, in fact, when doing some research on text alternatives for images. The way text alternatives should behave is described in The Roles Model – 5.2.7.3. Text Alternative Computation from WAI-ARIA. This describes “how user agents acquire a name or description that they then publish through the accessibility API” and it provides an order-of-precedence for the various bits of programmatically determinable text that can be used. The order of precedence should be:
- aria-labelledby
- aria-label
- alt attribute
- title attribute
What I found was a bit different and inconsistent across assistive technologies. This is definitely not a complete list of all scenarios or assistive technologies. There are also complex interplays between different browsers and Accessibility APIs, but it still illustrates the point that relying on the ideal behavior is as unrealistic when it comes to assistive technologies as it is when it comes to browsers.
When it comes to making design and development decisions, how likely are you to implement new HTML5 or CSS3 features without fallbacks? How likely are you to say, “Well, screw IE users for not supporting the <meter> element. I’m using it anyway!” Not at all, right? But you might be willing to come to that conclusion when it comes to box-model issues on IE6. These are the same types of considerations to put into assistive technology support. We must aim our efforts at the goal of achieving the greatest common good.
Thinking about this reminded me of the HTML Design Principles. “The principles offer guidance for the design of HTML in the areas of compatibility, utility and interoperability. ”
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
HTML Design Principles – Priority of Constituencies
This sort of sentiment could be used more than in just the design principles of the HTML5 specification. This should be how we handle all design and development topics – with the user first. The goal of any web design and development effort should be to ensure that we use HTML and CSS features in a way that the broadest reasonable range of people can use the system. Sometimes that will mean that users of certain brands or versions of assistive technologies will have a less-than-ideal experience. Some users, who choose to use software that doesn’t support modern technologies need to understand that their decision to use such software is impacting their enjoyment and productivity on the web. Other users may need to address their issues directly with the makers of their assistive technologies.
This does not absolve us developers from the responsibility of providing the broadest possible usability for all. That was the original reason for my research yesterday into text alternatives. What I found, in this particular cases, is that although there are multiple ways of providing a valid text alternative that should be supported by all modern screen readers, there’s only one approach that ensures usability for all users on all assistive technologies for all browsers on all operating systems. The tried-and-true ‘alt’ attribute. Modern browsers and assistive technologies can use aria-label or aria-labelledby, but such an approach doesn’t provide support for Voice Dictation Software or software/ user-agents that don’t support WAI-ARIA.
These are the types of decisions we make every day as web developers. Do we use the new shiny, or the tried-and-true? We need to answer that question from the user’s perspective, not from the development perspective – with the user taking preference.