Web Accessibility Basics What? Why? How?

When designing and developing IT-based solutions, as developers it’s often easy to fall into the trap of assuming that every user can see and use a pointer interface (such as a mouse or touch screen), this creates a tailored and polished experience for a narrow range of people, but this causes issues for anyone outside of that range. Accessibility, in this case, refers to those individuals who might be outside of that narrow range. And who might access or experience things differently to the way a “typical user” would. Specifically concerning users who are experiencing some type of impairment or disability, be that impairment situational, temporary or permanent.

You most likely can relate to using an interface which is not accessible, have you ever tried to use a desktop site on a mobile platform or been unable to locate/utilise the functionality you want within an application, so in a broad sense you have most likely been unable to access something.

Addressing accessibility often enhances the user experience for everyone, accessibility isn’t just a medical term that only applies to a certain percentage of people. Accessibility is something that concerns all of us, you and me, every day. What we create is useless if it isn’t accessible.

When developing web applications, the applicable standard/guidelines would be W3C’s Web Content Accessibility Guidelines (WCAG 2.0), which provides a list of recommendations which should be adhered to provide a more accessible experience, but it doesn’t end at adhering to WCAG as it has been shown “that only 50.4% of the problems encountered by users were covered by Success Criteria in the WCAG 2.0” [1], therefore go beyond these recommendations, however, they do provide a useful baseline.

 

Applications Natural Language

Informing the browser and other applications (such as assistive technology) via HTML which language content is being presented within your application has multiple benefits, these include but are far from limited to:

  • VoiceOver uses the attribute to auto-switch voices, for example speaking in a French accent for French content.
  • JAWS uses it to load the correct phonetic engine/phonologic dictionary.
  • It has positive benefits for SEO.
  • Allows third-party translation tools and browsers to identify the right language and/or dictionary.

The language codes are listed in the IANA Language Subtag Registry.

<html lang="en"> </html>

If the language alters within the application the ‘lang’ attribute should be specified on that specific content.

<p>There is a certain <i lang="fr">je ne sais quoi</i> present. </p>

Related WCAG 2.0 Success Criteria

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

How to Meet 3.1.1 Language of PageUnderstanding 3.1.1 Language of Page

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

How to Meet 3.1.2 Language of PartsUnderstanding 3.1.2 Language of Parts

Further Information

Benefits of using the Lang Attribute by Adrian Roselli. {Blog Post}

Screen Reader Demo: Lang Attribute by Léonie Watson. {Video}

Effect of Lang Attribute Values on JAWS by Steve Faulkner {Video}

 

Hidden Content

If you want to hide content both visually and from assistive technology, the ‘hidden’ attribute should be assigned, if you want content to only to be hidden to assistive technology then the ‘aria-hidden’ attribute should be used, however, this should be used with caution as this could result in important information becoming inaccessible to assistive technology users.

Therefore, in short, the ‘hidden’ attribute which was introduced in HTML5, tells browsers not to display the element, whilst the aria-hidden property tells assistive technology whether to ignore the element.

Note: Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies. [2] The same applies to the hidden attribute.

Examples

Hidden Attribute
<p hidden>These elements should be hidden both visually and to AT.</p>
<input id="input" type="button" hidden />
Hidden with ARIA-Hidden Attribute
<p hidden aria-hidden="true">These elements should be hidden both visually and to AT.</p>
<input id="input" type="button" hidden aria-hidden="true" />
ARIA-Hidden Attribute
<p aria-hidden="true">These elements should be hidden to AT.</p>
<input id="input" type="button" aria-hidden="true" />

 

Note: Hidden attribute is supported by the majority of browsers; however, support is not present for IE 10 or lower. The following CSS fall-back can be implemented, to catch these instances.
[hidden] {display: none;}

Further Information

Characteristics of States and Properties (ARIA-Hidden) by W3C

Hidden Attribute Browser Support by The Paciello Group

 

Alternative Text for Images

Alternative (alt) text should be assigned to all images implemented within the application, therefore enabling equivalent content/context of an image to be portrayed via text alone. If the image doesn’t portray content/context it’s still important to set the alt text, however, in these instances, the alt text should be set to null, for example, a background image which doesn’t imply content and/or context, therefore, is purpose being purely decorative.

If the image is purely decorative or doesn’t add valuable information, consider embedding it with CSS as a background image. If you have to add it in HTML, assign a null value to the alt text attribute as shown in the following code snippet.

<img src="decorative_image.jpg" alt="" />

It’s important that you don’t omit the alt attribute. A few tips on how and when to use the alt attribute:

  • Utilise the alt attribute on images which provide context, this should describe the function of the image and/or purpose.
  • Ensure that the alt Text defined is descriptive, for example, your company’s logo would be more appropriately your companies name rather than “Logo”.
  • Images used as links should have their alt text define as the destination of the link.
  • Use a null value for any image that is purely decorative or isn’t required for understanding the content/context of that specific page (alt=””), for example, if the content of an image is contained within the accompanying text, then that image’s alt text can be set to null.
  • If the same image is used throughout an application, this doesn’t mean that the alt attribute has to be consistently implemented, the image could have a variety of functions or portray different content/context in different situations, for example a logo could provide a link to a specific destination in one instance and be decorative in another, therefore the alt attribute should change with the corresponding change in context.

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 with images disabled (to save data).

Related WCAG 2.0 Success Criteria

1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)

  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • CAPTCHA:If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

How to Meet 1.1.1 Non-text Content |Understanding 1.1.1 Non-text Content

Further Information

Quick Tips: Using Alt Text Properly by The A11Y Project. {Blog Post}

Writing Effective ALT Text for Images by WebCredible (Trenton Moss). {Blog Post}

Five Golden Rules Compliant Alt Text by AbilityNet (Stefan Sollinger). {Blog Post}

References

[1] http://dl.acm.org/citation.cfm?id=2207736
[2] https://www.w3.org/TR/wai-aria/states_and_properties

 

This is just the beginning not the end, I will add more content as and when possible.

HTML5 Details and Summary Elements

The enhanced support for the HTML5 <details> and <summary> elements within browsers provide developers with an easier and often more accessible method of dynamically showing and hiding blocks of content. These elements have full keyboard support and are supported via the majority of assistive technologies. What are the Details & Summary Elements? The <details> and <summary> elements…