The Accessibility Project

A Primer To Vestibular Disorders

2013-05-15T00:00:00-07:00

Vestibular system — n The sensory mechanism in the inner ear that detects movement of the head and helps to control balance.

Imagine a world where your internal gyroscope is not working properly. Very similar to being intoxicated, things seem to move of their own accord, your feet never quite seem to be stable underneath you, and your senses are moving faster or slower than your body.

Your personal steady-cam is broken and whatever you look at tends to move regardless if you are moving. Let’s take that feeling and check out that great new website with animations and parallax scrolling. Does your stomach want to jump out of your throat? Well for many people it does.

What is it?

People with vestibular disorders have a problem with their inner ear. It affects their balance as well as their visual perception of their world around them.

Sometimes the sensation lasts only a short while, but others can suffer it for years. Walking becomes a challenge and they have a constant risk of falling. Concentration is diminished leaving the sufferer unfocused and often unproductive. It is often viewed as a “hidden” disability because it has no outward showing symptoms.

Who is at risk?

The cause may be from illness, injury, or from a genetic anomoly but anyone can suffer from a vestibular disorder. According to vestibular.org, a resource for people with vestibular disorders, as many as 35% of adults aged 40 years or older in the United States have experienced some form of vestibular dysfunction.

What should you consider?

Don’t make animations, sliders, rapid movement start automatically. Give an indicator of what movement will happen on the site when a user takes action. Allow the user the option to turn off any animation and movement.

How–to: Use Skip Navigation links

2013-05-11T00:00:00-07:00

Short answer: Use skip nav links in conjunction with a coherent heading outline and ARIA landmarks. You may need to also implement a javascript polyfill for Webkit based browsers.

It can be frustrating and fatiguing for folks with limited mobility to have to have to repeatedly tab through navigation links to get to the main content of a page. People who use screen readers face similar frustration when the page outline is not well defined. In order to address this issue, WCAG 2.0 has specified a guideline for bypassing repetitive blocks of content. One technique recommended by the W3C is to include a skip navigation link at the beginning of the page, that changes focus to the first element after the repeated content.

Skip nav links are useful for users who use keyboard navigation only, but screen readers now support more sophisticated ways of navigating regions. Specifically, they support heading navigation and ARIA landmarks. You should take advantage of these features by using a clear heading outline and defining page regions, as illustrated in Quick Tip: ARIA Landmark Roles.

Example

<body>
  <a href="#main">Skip to main content</a>
  <nav role='navigation'>
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
      <li><a href="/blog">Blog</a></li>
    </ul>
  </nav>
  <div id="main" role="main">
    <!-- page specific content -->
  </div>
</body>

Disclaimer: The mechanism by which skip navigation links work had for some time been broken in Webkit based browsers and has only recently been fixed. Until these browsers release the fixes, you may need to use a javascript polyfill to make skip nav links work.

Notes

Jim Thatcher pioneered skip navigation links as early as 1998
An example of a javascript polyfill by Nicholas C. Zakas.

How–to: Use TITLE attributes

2013-04-22T00:00:00-07:00

Short answer: Don’t use them, except in special circumstances.

HTML title attributes are often perceived as an accessibility (and SEO) bonus, but the opposite is true. For screen reader users the content included inside of the title attribute is typically unncessary, redundant, and possibly not even used. Conversely, content being put in the title attribute is being hidden from the (probable) majority of your users. If information is being hidden from the majority of your users, then it’s probably not necessary.

There are a few times when using a title attribute is appropriate:

For <frame> and <iframe> elements
For providing a label when a text label would be redundant

Rule of Thumb: Serve all users equal content.

MYTH: Screen readers don’t use JavaScript

2013-04-21T00:00:00-07:00

A common misconception among web developers is that screen readers only read the non-JavaScript page. Due to this misconception, we sometimes assume it’s unnecessary to make JavaScript apps and other functionality accessible. This is categorically false.

According to a May 2012 survey conducted by WebAIM, 98.6% of screen reader users have JavaScript enabled.

Be sure to make efforts to ensure that all functionality (apps, custom UI controls, forms, etc) within your site is accessible with JavaScript enabled as well as provide accessible fallbacks for the 2% of users (globally) with JavaScript disabled. A good starting point might be to use native anchor links and form inputs instead of custom scripted form elements.

Futher Reading

How–to: Use role="application"

2013-02-09T00:00:00-08:00

NEVER use role="application" on a widely containing element such as <body> if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode. Using role="application" unnecessarily can cause huge headaches for any assistive technology user trying to use your site/application. Only put it on the <body> element if your page consists solely of a widget or set of widgets that all need the focus mode¹ to be turned on.

Use sparingly.
If your page has no resemblance to a classic document in roughly over 90% of its content.
Use clear labels within your application.

Don’t

If a set of controls or user interface only contains these widgets that are all part of standard HTML²
If your widget is dynamic such as a tree view, slider or table.

Unless you take a great deal of care in ensuring that you’ve recreated a lot of native–ish custom navigation, it’s almost always better to leave the browser/AT to its own devices. We really only recommend it on a per–in–page–widget basis, and even then: very, very carefully.

References:

Allows the user to interact with forms and ARIA–enabled HTML elements.
↩
Standard HTML refers to: text, password, search, tel and other newer input type derivates, textarea, checkbox, button, radio button (usually inside a fieldset/legend element wrapper), select & option(s), links, paragraphs, headings, and other things that are classic/native to documents on the Web.
↩

Quick Tip: Never remove CSS outlines

2013-01-25T00:00:00-08:00

Use of the rule :focus { outline: none; } to remove an outline results in the link or control being focusable but with no visible indication of focus for keyboard users. Even worse, methods to remove it such as onfocus="blur()" result in keyboard users being unable to interact with the link or control.

If you do not like the default focus outline that is displayed when a user clicks on an interactive element, you have 3 accessible solutions:

Style the outline. Webkit browsers have a more prominent glow so you could try styling it to make it less obtrusive. Consider the use of a:focus { outline: thin dotted; } to normalize the look of the outline across browsers.
Style the element itself. You can remove the outline as long as you style the focused element differently (using color, background-color, border or text-decoration: underline for example).
Remove outlines for mouse users only, if you truly must do so. Start without applying any outline: none rules. If a mouse event is detected apply those rules using JavaScript. Remove the rules again if keyboard interaction is detected. Here are 2 examples of accessible outline removal scripts:
- outliner.js, a cross-lib implementation with event delegation, by Aireh Glazer
- outline.js, a similar approach that uses mousedown instead of mouseover, by Lindsay Evans
Consider this third solution as a last resort. Some browser/screen reader combinations fire mouse events, which could cause outlines to disappear while using this method.

In conclusion, using outline: none without proper fallbacks makes your site significantly less accessible to any keyboard only user, not only those with reduced vision. Make sure to always give your interactive elements a visible indication of focus.

Quick Test: Check Comprehension Level

2013-01-25T00:00:00-08:00

Estimated time: 3 minutes

Cognitive disabilities affect more than 6% of the population. People with cognitive disabilites often struggle with reading text on the internet. When writing content, it is important to identify your target audience and write accordingly. If you don’t know who your target audience is, target your content towards a reader between the ages of 12 and 15 years old.

Here are some tools to test your content:

If your content isn’t hitting the target audience, take some time and rewrite it.

A Primer To Visual Impairment

2013-01-22T00:00:00-08:00

Over 285,000,000 people suffer visual impairment, a condition that limits the visual capability of an individual to such a degree that additional support is needed. Visual impairment is the result of trauma, disease, congenital or degenerative conditions that cannot be corrected by medication, surgery or refractive correction. 90% of the world’s visually impaired live in developing countries and 80% of all visual impairment can be avoided or cured by conventional means.

There are 3 levels of visual impairment:

Moderate visual impairment
Severe visual impairment
Blindness

Who Is At Risk?

65% of visually impaired are over 50 years and with an ever increasing elderly population in many countries, more people will be at risk of age-related visual impairment. An estimated 19,000,000 children under 15 years are visually impaired with 12,000,000 due to refractive errors that have not yet been diagnosed or corrected, while 1,400,000 are irreversibly blind.

The Causes?

Disorders of the eye that lead to visual impairments can include retinal degeneration, albinism, cataracts, glaucoma, muscular problems, corneal disorders, diabetic retinopathy, congenital disorders, infection and cortical disorders.

Refractive errors (myopia, hyperopia or astigmatism) are typically the result of nature with 43% of visually impaired born with refractive errors that can be corrected with medication, surgery, glasses or contact lenses.

The Challenges?

Before the industrial revolution, people with visual impairment were condemned to a life of confinement where opportunities of education and employment were unheard of. Since this time the rights of visually impaired people have been fought for and as a result improvements in accessibility that now allow people with low visual accuity to live full and independant lives in place of bygone institutionalization.

Equality is the most important challenge that faces those with visual impairment and the improved accessibility to technology, braille and other tools that aid in daily life, the rest of the world is beginning to understand that the visually impaired population are capable of the same things as those with near perfect vision.

Although the visually impaired community has seen new opportunities, these are not foolproof solutions to everyday challenges and a greater dependence on what we might take for granted is very important. Electricity is a huge factor when it comes to content as without electricity a person who relies solely on a screen reader cannot simply browse a book, magazine or newspaper. This inturn puts greater demand on media that originated in print to be made available through computers where screen readers can assist in accessibility to content.

The Future’s Bright

Louis Braille invented the Braille system for reading and writing in 1824, giving access to previously inaccessible literature. Helen Keller overcame the institutionalized education system of the 19th century, becoming the first deafblind person to earn a Bachelor of Arts Degree. Bob Stepp in 1980 developed the first Braille editing program, and in the modern era of internet we hold the key to accessibility for this generation and many more to come.

The challenges of yesterday are the opportunities of today.

How-to: Future proof your accessibility efforts.

2013-01-22T00:00:00-08:00

Future proofing your accessibility work will help lower your development costs as well as support current and future user agents, such as assistive technologies (AT). WCAG has two guidelines, Parsing and Name, role, value, for future-proofing your website.

Parsing relates to ensuring that user agents and AT are able to read and navigate your web site correctly. Validating your site using the W3C Markup Validator can help you find errors in your markup and ease the burden of the AT parsing your web page. Follow the official specifications for your markup. E.g. make sure to close open tags (<div class="a-class">...</div>) and use unique IDs.
Name, role, value are related to interface components and controls (i.e, focus states). By default, all standard HTML controls already meet this criteria. This guideline is aimed mainly at developers that design and/or script their own interface components and controls.

While these are only two recommendations to make your site more accessible, it should have a good spot in every web developer’s workflow. Use of checklists, like The Accessibility Project checklist, can help keep you on task.

Quick Test: Check contrast with your mobile device

2013-01-22T00:00:00-08:00

Estimated time: 3 minutes

Having good contrast and readability are an important part of creating an accessible website. One trick you can do to test whether or not your contrast is sufficient enough is by using your phone or mobile device.

Set the brightness of your mobile device to its lowest setting.
Open up your website on the device and begin browsing around.

If you find something difficult to read, congratulations, you may have found an accessibility issue! Take measures to check and increase the contrast of your text.

Quick Tip: Don't auto-play video, music and more

2013-01-15T00:00:00-08:00

Summary: don’t auto-play and it will please all of your users.

Sound

People using screen-readers navigate by listening, so any sound playing when the page loads will interfere immensely.

In a note on audio control, WCAG 2.0 suggests:

Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.

It will also be frustrating to any user that may be listening to music or is in a quiet area with their sound on high.

Vision

Vision includes video and CSS/JavaScript animations like slide-shows and carousels.

Some groups of people, such as those with certain types of learning difficulties, can find it hard to concentrate or focus on tasks. These groups may have a problem with moving content on a web page that starts without warning.

In HTML5

The new HTML5 specification includes the autoplay attribute along with the following provisions:

Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired, e.g. when using a screen reader.

Even though an autoplay attribute is included they also suggest:

Authors are also encouraged to consider not using the automatic playback behavior at all, and instead to let the user agent wait for the user to start playback explicitly.

What if you can’t say no?

We, as web developers, don’t always have the luxury of making the business decisions so there are some recommendations to follow (“the clip” - a video, sound clip, animation):

Ensure the clip lasts for five seconds or fewer before stopping for good
If the clip lasts over five seconds you must provide the user with an option to stop or pause it
It is generally accepted that if the user was aware, when they clicked a link, that the proceeding page would auto-play - for example a link to YouTube

Quick Tip: Never use maximum-scale=1.0

2013-01-14T00:00:00-08:00

Using the viewport meta tag the wrong way can hinder users with visual problems accessing your website. By setting maximum-scale=1.0, you are disabling the functionality to use pinch zoom on mobile devices, and forcing users to view your page a certain way.

The bad way:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">

The good way:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Avoiding maximum-scale=1.0 allows your site to meet users’ needs and provide a better experience.

Getting Started with OS X VoiceOver

2013-01-14T00:00:00-08:00

VoiceOver is the assistive software built into OS X. It provides a richer set of keyboard shortcuts for navigating a website and reads sections of the page aloud based on the current focus. It’s a great way to test the accessibility of a project because it’s always readily at-hand: you can toggle VoiceOver on/off by:

Toggling it to “on” under “Universal Access” in your system preferences.
Pressing ⌘+F5

Turning on VoiceOver enables a number of navigational key commands, all of which are performed by pressing Control and Option. This is usually abbreviated to “VO” in Apple’s documentation (so “VO-F1” means “control-option-F1”).

To start out, try turning on VoiceOver with ⌘-F5, then use VO-F8 to open VoiceOver’s preferences window—here you can adjust things like the voice used, speaking speed, and under “web”: your navigation method.

Navigation Modes

There are two modes you can use when navigating with VoiceOver: by “grouping items” or by “DOM order.” These two methods allow you to interact with a page’s content in slightly different ways.

Grouping items will flag that you are currently focused on a list, and you can begin interacting with the items by pressing the down arrow to “drill down” into those items. This mode attempts to group related content based on how the page is being rendered, and navigating by group will allow you to use the arrow keys to move in any direction. We’ll be focusing on this mode.

DOM Order will flag that you are entering a list of items, and drill down into those items automatically. This mode is based entirely on the page’s underlying markup. Navigating by DOM order allows you to shift focus between DOM elements with the left and right arrow keys. The up and down arrow keys are based on the last used navigation method in the “Web Item Rotor.”

The Web Item Rotor

Open the rotor by pressing VO-U with VoiceOver enabled, and you’ll be presented with a list of navigational elements on the current page. You can use the rotor to jump directly to links, headings, form controls, tables, web spaces, and ARIA landmarks. You can switch between these navigation methods using the left and right arrow keys, navigate through the list using the up and down arrow keys, and select an item using the enter key or the spacebar.

You can start getting a feel for VoiceOver right here on a11yproject.com. Try it out!

Quick Tip: ARIA Landmark Roles

2013-01-14T00:00:00-08:00

ARIA Landmark Roles help assistive devices navigate your site. Important roles to be aware of include:

banner – Typically the “header” of your page that includes the name of the site
search – For the search form
form - Group of elements that as a whole, assemble a form (please note that there isn’t a great deal of legacy support for this role)</li>
main – This would designate the main content area on your site
navigation – Use on any navigation list, typically on the nav element
contentinfo – Typically the “footer” of your page that contains information about the parent document such as copyrights and links to privacy statements

To add a role to an element, simply add the “role” as an attribute:

<header role="banner" class="site-header">

Quick Tip: Using alt Text Properly

2013-01-14T00:00:00-08:00

A few tips on how and when to use the alt attribute:

Use the alt attribute for any image that is used as content. alt text describes the function of an image, and is rarely a detailed description of the image itself (unless, for example, the page is actually about a specific picture).
Make sure the description of the image is useful. For example, if the image is your logo your alt should be your company name and not “logo”.
Images that are links should describe where they go. For example, a logo that is a link to your home page should have alt="home page".
Don’t begin alt text with “photo of..” or “picture of..”; assistive technologies already do this. Redundancy and repetition are almost as bad as not enough information.
Use an empty alt attribute for any image that is decorative or not necessary for understanding the content of the page (alt=""). If, for example, the information in a graph is explained in text below it, there’s no need to duplicate that in alt text.
Using a image file several times in a website doesn’t mean that the alt attribute has to be the same in each img tag. Because alt attribute change with context. For example, as seen above, a logo that is a link to your home page should have alt="home page" and the same logo, used somewhere else as decoration, should have alt="".

The alt attribute is meant to help users not miss any content, so make sure your text is helpful to anyone not seeing the image. These could be assistive technology users or users of a mobile with images turned off (to save data, for instance).

Quick Test: Navigate using just your keyboard

2013-01-11T00:00:00-08:00

Estimated Time: 5 seconds

One quick way that you can check your accessibility is to navigate through the site using nothing but your keyboard.

Un-plug/turn off your mouse.
Use the Tab key browse.
Use Enter to select elements.
Some menus and form elements may require ↑ ↓ ← → arrow keys.

This is by no means a complete accessibility check, but it can quickly help you find major accessibility problems.

MYTH: Accessibility is "blind people"

2013-01-11T00:00:00-08:00

Accessibility is often viewed as making your site work on screen readers. In reality, web accessibility is a subset of UX focused on making your websites usable by the widest range of people possible, including those who have disabilities.

Four Categories of Accessibilitiy

Accessibility can be broken down into four key categories¹.

	Associated Conditions
Visual This can be non-sighted users, users with low-vision, users with obstructed vision, or even simply your aging parents.	Myopia Colour blindness Glaucoma Albinism
Auditory The web is a visual medium, but captions and fallbacks for sound-necessary media need to be considered for hearing impaired users.	Presbycusis Acoustic trauma Auditory processing disorder Otosclerosis
Motor People with motor impairments typically use a wide range of assistive technology from specialized keyboards, to eye trackers, to using single buttons to navigate their computer.	RSI Cerebral palsy Parkinson's Muscular dystrophy
Cognitive Relates to the ease processing of information.	Down’s syndrome Autism Global developmental delay Dyslexia

Temporary Disabilities

While each of these disabilities are usually permanent, there are often situations in which even fully-abled people are ‘temporarily disabled’ such as having an arm injury may prevent you from being able to use a mouse. Robin Christopherson (an accessbility expert who is blind) once spoke about how people that are driving but use hands-free sets or have their phone connected to the car radio are ‘temporarily disabled’ as they use the phone differently to how they normally would. Of course, most people do not need to browse websites while they are driving but it is important to understand different situations like that, where the user may not have special software installed that a disabled user might.

As you can see, there are a variety of different users with different needs and concerns across the web. We will cover each category further in detail as they relate to accessibility on the web.

Simple Introduction to Web Accessibility by Ian Hamilton (.net Magazine)
↩

How-to: Hide Content

2013-01-11T00:00:00-08:00

Developers commonly use display: none to hide content on the page. Unfortunately, this simple and common action is a bit problematic for screen readers.

Screen readers sometimes ignore display:none¹. This means the content will be read despite being “hidden”. To hide content completely from screen readers use the following:

/* http://www.456bereastreet.com/archive/200711/screen_readers_sometimes_ignore_displaynone/ */
.hidden {
    display:none;
    visibility:hidden;
}

And for good measure you could consider adding the ARIA attribute aria-hidden="true" to the element.

There are also real world situations where you want to hide elements (e.g., a form label), but you still want text to be read by a screen reader. The “clip pattern” will hide the content visually, yet provide the content to screen readers². Unlike positioning and negative text-indent, it works with rtl languages for localization.

.visually-hidden { /*http://developer.yahoo.com/blogs/ydn/posts/2012/10/clip-your-hidden-content-for-better-accessibility/*/
    position: absolute !important;
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px);
    padding:0 !important;
    border:0 !important;
    height: 1px !important;
    width: 1px !important;
    overflow: hidden;
} 
body:hover .visually-hidden a, body:hover .visually-hidden input, body:hover .visually-hidden button { display: none !important; }

Consider adding these HTML classes and CSS rules to your base stylesheet and use them when applicable.

Screen readers sometimes ignore display:none 456 Berea Street (November 7, 2007)
↩
Clip Your Hidden Content For Better Accessibility Yahoo Accessibility Blog (October 23, 2012)
↩

The Accessibility Project

A Primer To Vestibular Disorders

What is it?

Who is at risk?

What should you consider?

How–to: Use Skip Navigation links

Example

Notes

How–to: Use TITLE attributes

Further reading

MYTH: Screen readers don’t use JavaScript

Futher Reading

How–to: Use role="application"

Quick Tip: Never remove CSS outlines

Quick Test: Check Comprehension Level

A Primer To Visual Impairment

Who Is At Risk?

The Causes?

The Challenges?

The Future’s Bright

How-to: Future proof your accessibility efforts.

Quick Test: Check contrast with your mobile device

Quick Tip: Don't auto-play video, music and more

Sound

Vision

In HTML5

What if you can’t say no?

Further reading

Quick Tip: Never use maximum-scale=1.0

Getting Started with OS X VoiceOver

Navigation Modes

The Web Item Rotor

Quick Tip: ARIA Landmark Roles

Quick Tip: Using alt Text Properly

Quick Test: Navigate using just your keyboard

MYTH: Accessibility is "blind people"

Four Categories of Accessibilitiy

Visual

Auditory

Motor

Cognitive

Temporary Disabilities

How-to: Hide Content