Legal Exposure and Equal User Experience

Although legal exposure is a valid concern—users can sue companies for inaccessible websites and apps just as they can sue over inaccessible buildings and facilities—there are positive reasons to maintain accessibility. Accessibility lets your organization provide a more equal user experience, helping you reach the broadest customer and stakeholder base possible. Consider that:

• More than five percent of people worldwide have a hearing impairment.
• 15 million people in the U.S. have a vision impairment.
• 41 percent of videos online do not include sound or captions and are incomprehensible to hearing or visually impaired users.

In addition, accessibility can improve search engine optimization (SEO) and is often appreciated by users without impairments, such as older users who desire larger text.

W3C Web Accessibility Initiative (WAI)

The World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) provides standards to ensure web and app accessibility. Most important are:

 
• WCAG – W3C’s Web Content Accessibility Guidelines (WCAG), which provide three levels of compliance (A, AA and AAA). Level AA compliance is appropriate for web and app developers. (LINK)

 

• ARIA – W3C’s Accessible Rich Internet Applications (ARIA) guidelines. (LINK)

 
NOTE: Section 5 of the Federal Rehabilitation Act also covers accessibility. However, if you comply with the WCAG (AA) and ARIA guidelines you also will be section 5 compliant.

The POUR acronym

The WCAG guidelines support principles are summed up by the acronym POUR, which stands for Perceivable, Operable, Understandable and Robust. Websites and applications should be:

 
• Perceivable – providing alternatives for non-text and time-based media (such as captioning or transcripts for videos, and text for images), compatibility with different devices and browsers, and generally making it easier to see and hear content.

• Operable – providing ways for users to interact via keyboard, without a mouse, and including the ability to slow down or run at various speeds. Sites should be very navigable and not cause seizures or physical reactions.

• Understandable – done in readable, simple language, avoiding complex terminology unless required by the subject matter. Content should appear and operate in predictable ways – from top to bottom and left to right (or right to left in countries where people read that way). Build pages and sites to help the user avoid mistakes.

• Robust – meaning the site or app can be interpreted by a wide variety of user agents, including assistive technologies.

These four main high-level guiding principles that are used in functional accessibility design and development are commonly referred to as the POUR acronym and are meant to improve the lives of people with disabilities, expand business markets, and help to avoid lawsuits and bad press coverage.
 

What is ARIA

ARIA stands for Accessible Rich Internet Applications and is a set of attributes you can add to your HTML to help define elements (i.e. content and images) so users working with assistive technologies (AT) can access the information. Some ARIA examples of this include:

• Roles – roles define what an element is or does. An example of this might look like 

Role Example:    <nav role-“navigation”></nav>

• Properties – properties can provide more semantics. Some examples of this might look like:

Global Example:    aria-describedby=”info”

Widget Example:   aria-hidden=”true”

Live Region Example:    aria-live=”polite”

Relationship Example:    aria-colspan=”2″

• States – states define “a state” an element is in . An example of this might look like:

State Example:    aria-disabled=”true”

ARIA guidelines are categorized by Roles, Properties and States. Roles define what an element is or does. If the role says “navigation,” for example, it will allow screen readers to announce to the user that they are viewing a navigational element.

ARIA Global Attributes

ARIA properties and roles consist of global attributes that can be applied to all elements, and include specialized ones for widgets, live regions, and relationships. Examples of each include:

 
• Global Property – an example of a global property would be a field on screen that is described from a text paragraph. The “described by” element would cause the paragraph to be read out to the user.

• Live Regions – live regions are a property used for things that refresh on the screen frequently, such as news feeds or stock quotes, to notify a visually impaired user when the area changes.

• Relationship Property – the relationship property is ideal for use with tables, announcing to the user contextual row and column header names so user knows what row/column category they are inside

ARIA Global Attributes (states & properties) provide specific information about an object and help form a description of the roles nature. This all falls into the category of WAI-ARIA, which is a specification written by the W3C. ARIA defines a set of additional HTML attributes that can be tagged onto various elements and gives the code additional semantics to help improve accessibility for the user.
 

Accessibility

 
Accessibility compliance can require extra effort in design and testing. This is particularly true with video, which requires captions for the hearing impaired and transcripts for the visually impaired. For closed captioning and transcription, it makes sense to leverage third-party services.
 
Finally, although accessibility is generally desirable, not every website or application must be accessible, particularly those whose target audience by definition does not have impairments (for example, police officers in the field). Ultimately, the choice to provide or not provide accessibility is up to each organization, preferably with input from legal counsel.