Accessibility

ARIA attributes
By John Durance
Complex widgets – like a carousel – create more engaging and user-friendly interfaces. They're great for users who have good vision, but not always so great for those using a screen reader. Problems arise if understanding breaks down between the widget running in the user agent and the accessibility API. This breakdown causes the assistive technology to fail too.
Adding semantics
By John Durance
A problem that screen readers often face is drawing sufficient semantic meaning from a document.
Describing images and forms
By John Durance
The alt attribute is set on the img element; it specifies alternative information for users who cannot see an image. All images should have one. If an image is missing this attribute, the screen reader will read out the file name of the image – very annoying for the user, if the file name is a long string of random characters and numbers. For decorative images the alt attribute should be set to an empty string. This tells a screen reader to skip over it. For all other images, provide a concise informative desciption of the image.
Managing focus
By John Durance
For keyboard-only users you can think of focus as their cursor. Focus is moved forwards with the Tab key, backwards with Shift-Tab, and it can jump to another region via a keyboard shortcut. Most browsers display focus as an outline around the focussed element. Some users cannot see this outline, but they can still be aware of where focus is, if it's managed correctly.
Adding key handlers
By John Durance
For complex widgets, which are unable to use semantic markup, it's a good idea to add key handlers so that users can interact with them via the keyboard. In this code, the example function can be called by clicking, or by moving the focus and hitting A:
Creating a logical DOM
By John Durance
The Document Object Model (DOM) is an API for HTML and XML documents. It defines these documents as tree structures, which can be accessed and manipulated. Screen readers look into the DOM, not at what is displayed on the web page/application. Keyboard-only users navigate the DOM in order, from top to bottom, moving focus to navigate up and down. Blind and low-vision users will, likely, be unaware if elements on the web page have been visually re-ordered with CSS. This is why it's important to have DOM elements ordered logically. For example:
Keyboard interaction: special keys and shortcuts
By John Durance
On a web page/application, the 'special' keys – Tab, Space, Esc etc. – can perform generic keyboard interactions. They move the focus to the next or previous element, or they open or close something, or they start or stop a process. Sometimes, their functions can be reversed or altered by holding down the Shift, Ctrl, or Alt keys simultaneously. A well designed keyboard interaction should behave in a way that a user would intuitively expect it to.
Aural interaction and screen readers
By John Durance
A visual interface expresses information about the state of a web page, or application, through a visual language. For example, links are a different colour to the rest of the text indicating that, if clicked, another page will load. Also, a link's colour may change if the cursor hovers over it. The cursor, too, may change from an arrow into a pointer. The problem is that users who cannot see a visual interface receive none of these visual cues. One way to overcome this problem is to express this basic language through speech: aural interaction.
Why create accessible websites?
By John Durance
If you think about it, we interact with our desktop computers mostly with our hands and our eyes. Our hands are on the keyboard or mouse; our eyes are looking at the screen. However, some users cannot make use of a screen or a mouse. They may be blind, or have low vision, or may not have fine motor skills with their wrists, hands and fingers. If we don't make our websites univerally accessible, we risk losing out on the contributions these users have to make: their ideas, donations, bug fixes, purchases, stories etc.