There was a time when
Back to Earth
Unfortunately, ARIA is not well supported yet. Only the latest versions of (very expensive) screenreaders have any support, and none of them support everything. Additionally, the bits that are supported, aren’t necessarily implemented properly.
Users of Assistive Technologies
The first group includes people using screenreaders, braille readers, or similar assistive technologies. The blind are chief among this group, but it also includes people with low vision and cognitive disabilities, who use screenreaders to aid reading and comprehension.
Text alone is not enough, if it doesn’t have structure and relationships that assistive technologies can understand programatically. Text is usually structured in very simple ways such as lists and tables. These are structures that assistive technologies can easily understand. All we need to do is use them properly.
By building things like dropdown menus using unordered lists and structural labels, assistive technologies can derive their meaning from the semantics and hierarchy of those elements. Or, we can build calendar widgets where each month’s view is a table. We can then trigger it with a button and describe it with a label. Solid element semantics should be the basis of all interactive content.
Keyboard support often comes for free, if you follow the premise that the best event is the most device independent. So, form validation should be tied to the form’s modeless
submit event, while primary activation events should be bound to the universal
click event, rather than mode-specific events like
For more complex interactions, a combination of events is often required. The Web Content Accessibility Guidelines talk about
event pairings – pairing mouse events with their nearest keyboard equivalent. An example pairing would be the
keydown events. However, this is the wrong way of looking at it, because it focuses on the mechanics of an activity rather than the purpose. It shouldn’t matter if the keyboard way of doing something is completely different, as long as it achieves the same purpose.
For something like drag and drop, there is no keyboard equivalent to the
mousemove event, but we can still make it accessible to the keyboard. What we refer to as drag and drop is actually two different kinds of interaction. The first is where elements can be moved up and down to sort them, and this could be implemented using simple Up-Arrow and Down-Arrow keystrokes. The second is grab and move actions like dragging files between folders, and this could be done with something like Space to select an element, then Tab to select the drop-target, then Enter to drop it.
When non-obvious keystrokes are used, there should be accompanying text to explain them. And, in truth, some keyboard interactions will inevitably be more convoluted than their equivalent mouse interactions. But that doesn’t necessarily matter, as long as it does the same job. Accessibility is about equivalence, not equality.
Another important consideration with keyboard accessibility is maintaining a logical content-order. For example, when rich tooltips are used, they must be inserted directly after the element that triggered them, so you can Tab to them straight away and so that screenreaders read them next.
Users Who are Sensitive to Flashing Content or Time Limits
The final group is people who are sensitive to flashing or blinking content, or who can’t respond to real-time events in the expected way. As far as flashing content is concerned, this affects people with photosensitive epilepsy for whom a seizure can be triggered by such effects, as well as people who have a cognitive disability and find it more difficult to concentrate when things are moving in their peripheral vision. Limits on flashing content are defined quite specifically by the WCAG, and summarized as the Three Flashes or Below Threshold.
The general principle for time limits is that whenever an activity has to be completed within a certain time, the user is warned when the time limit is about to expire and provided with a way to extend it. For example, an online banking interface might have strict time limits on session inactivity, but user control could be provided with a simple
confirm dialog (just as you see on ATMs when they ask if you need more time).
When content is animated, the animation shouldn’t last more than five seconds, unless there’s a way for the user to control it. An animation might be a purely decorative effect, and so the time restriction is helpful for people who have a cognitive disability, for whom constant peripheral animation can make it harder for them to focus on the main content.
Alternatively, animation might be scrolling or moving content, and here the restriction is to allow users to complete a task without unexpected changes of context. For example, a news ticker which scrolls automatically should have a pause button, so the user can read each item at their own speed, and be confident it won’t change while they’re reading it! Similar logic applies when large blocks of content, or whole pages, are automatically refreshed. This is common on sites that contain stock information or sports results. You simply shouldn’t do this at all, unless you provide explicit user-control over the refresh frequency (which defaults to never).
But time limits are often an integral part of the activities they’re used for. Many games are inherently timed-based, and removing the time restriction would negate the purpose of the game. In such cases, it’s fair to say that the content simply can’t be made accessible without changing its meaning. The WCAG allows for this possibility, as long as the content is clearly described as such.