Main content

Debra Kyles

I am an Accessibility Engineer,  working with accessibility for about ten years. I have also worked as a UX Designer for about fifteen years. I’ve worked with governments, enterprise businesses, educational institutions and small IT shops.

A few highlights of my work:

  • ·        Helped the University of Minnesota in their efforts to make a PeopleSoft site accessible using a Javascript overlay.
  • ·        Prepared an Accessibility Approach and Plan document for a T-Mobile redesign.
  • ·        Helped Getwell Network make their hospital-based platform accessible.
  • ·        Trained staff at CalPERS (California Public Employee Retirement System) and the Legislative Data Center to test, validate and fix accessibility issues.
  • ·        Served as SME for the State of California EDD modernization project
  • ·        Served as accessibility expert for the National Institute of Standards and Technology to define standards for accessibility in cloud computing.

I love making the web a better place for the 20% of the population who are challenged with disabilities. By including this population in our design, copy and coding decisions, we make the world a more compassionate, empathetic place to live.

Visiting a web page might have several reasons. The straight reason any person come to a page is for gathering some information or completing a particular task. Apart from that, users may navigate a webpage in the process of searching some information, in the way of navigating to other page etc.

Keeping various users in mind the web page will be divided into several regions. Web page contains “Navigation area”, “Main content area”, “Footer area” etc. This division of the web page will not be available to the users of assistive technologies.

ARIA landmark roles helps in bridging this gap. ARIA landmarks provide systematic way of conveying the various divisions of the web page to the users of screen readers. In this post we will understand how the screen readers handle land mark roles.

  • Banner
  • Navigation
  • Search
  • Main
  • Form
  • Contentinfo
  • Complementary

A region that contains the prime heading or internal title of a page.

Syntax:
<div role=”banner>
</div>

Screen Reader support

  • JAWS recognizes the beginning and end of the banner region and announces “Banner Region Start” and “Banner Region end.
  • NVDA 2012.3 recognizes the beginning of the banner region but could not announce when it ends. NVDA announces “Banner Region start” at the beginning of the banner landmark.
  • VoiceOver on IOS recognizes banner landmark but it announces “landmark start” and “landmark end”. It does not say which landmark it is.
  • Talkback on Android says just “Banner” at the beginning of the landmark. It does not identify the end of the landmark.

A collection of links suitable for use when navigating the document or related documents.

Syntax:
<div role=”navigation”>
</div>

Screen reader support

  • JAWS recognizes the beginning and end of the navigation region and announces “Navigation Region Start” and “Navigation Region end.
  • NVDA 2012.3 recognizes the beginning of the Navigation region but could not announce when it ends. NVDA announces “Navigation landmark” at the beginning of the Navigation landmark.
  • VoiceOver on IOS recognizes Navigation landmark but it announces “landmark start” and “landmark end”. It does not say which landmark it is.
  • Talkback on Android says just “Navigation” at the beginning of the landmark. It does not identify the end of the landmark.

The search tool of a Web document.

Syntax:
<div role=”search”>
</div>

Screen Reader support

  • JAWS recognizes the beginning and end of the search region and announces “Search Region Start” and “Search Region end.
  • NVDA 2012.3 recognizes the beginning of the Search region but could not announce when it ends. NVDA announces “Search Region start” at the beginning of the search land mark.
  • VoiceOver on IOS recognizes search land mark but it announces “landmark start” and “landmark end”. It does not say which landmark it is.
  • Talkback on Android says just “search” at the beginning of the landmark. It does not identify the end of the landmark.

Main

Main content in a document.

<div role=”main”>
</div>

Screen Reader Support

  • JAWS recognizes the beginning and end of the main region and announces “Main Region Start” and “Main Region end.
  • NVDA 2012.3 recognizes the beginning of the Main region but could not announce when it ends. NVDA announces “Main landmark” at the beginning of the Main land mark.
  • VoiceOver on IOS recognizes Main landmark but it announces “landmark start” and “Landmark end”. It does not say which landmark it is.
  • Talkback on Android says just “Main” at the beginning of the landmark. It does not identify the end of the landmark.

Content info

Meta information which applies to the first immediate ancestor whose role is not presentation.

<div role=”contentinfo”>
</div>

Screen Reader support

  • JAWS recognizes the beginning and end of the Contentinfo region and announces “Contentinfo Region Start” and “Contentinfo Region end.
  • NVDA 2012.3 recognizes the beginning of the Content info region but could not announce when it ends. NVDA announces “Contentinfo landmark” at the beginning of the Content info landmark.
  • VoiceOver on IOS recognizes Contentinfo landmark but it announces “landmark start” and “landmark end”. It does not say which landmark it is.
  • Talkback on Android says just “Contentinfo” at the beginning of the landmark. It does not identify the end of the landmark.

Complementary

Any section of the document that supports but is separable from the main content, but is meaningful on its own even when separated from it.

Syntax:
<div role=”complementary”>
</div>

Screen Reader Support

  • JAWS recognizes the beginning and end of the Complementary region and announces “Complementary Region Start” and “Complementary Region end.
  • NVDA 2012.3 recognizes the beginning of the Complementary region but could not announce when it ends. NVDA announces “Complementary landmark” at the beginning of the Content info landmark.
  • VoiceOver on IOS recognizes Complementary landmark but it announces “landmark start” and “landmark end”. It does not say which landmark it is.
  • Talkback on Android says just “Complementary” at the beginning of the land mark. It does not identify the end of the landmark.

Form

A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.

<div role=”form”>
</div>

Screen Reader Support

  • JAWS recognizes the beginning and end of the Form region and announces “Form Region Start” and “Form Region end.
  • NVDA 2012.3 do not recognize the Form region.
  • VoiceOver on IOS do not recognize Form landmark.
  • Talkback on Android says just “Form” at the beginning of the landmark. It does not identify the end of the land mark.

Other Notes:

  • Use JAWS short-cut key “;” (semi column) to jump from one landmark to another landmark on the web.
  • Use NVDA short-cut key “d” to jump from one landmark to another landmark on the web page.
  • NVDA provides the landmarks list from “Elements list” which can be pulled out by using short-cut insert + f7.
  • VoiceOver on IOS provides landmarks under the rotor elements.
  • JAWS does not recognize Form landmark on Google Chrome.

Must

Section 508:

  • §1194.21(d)
  • §1194.22(a)

WCAG 2.0:

  • 1.1.1 (A)

Alternatives should briefly describe the editorial intent or purpose of the image, object, or element

When alternatives are provided for actionable items such as buttons, and image links the alternative should describe the action that will be performed. For example, "Play" or "Rate this article". Verbose alternatives make content harder to listen to and understand for screen reader users. Avoid the use of 'Image of...'. 'Link to...", 'Picture of...' etc.

The type or trait of an object should also not be described in the alternative as this will be programmatically determined by the screen reader. For example a ‘Play’ button coded as a button with the alternative ‘Play’ will be read as ‘Play, button’. If the alternative is ‘Play button’ the screen reader user will then hear ‘Play button, button’.

iOS

Add concise alternatives via the accessibilityLabel attribute. Alternatives must begin with a capitalised word and must not have a full stop (.). Supplementary information should be provided in the accessibilityHint property. The accessibilityHint property should describe the results of performing the action if the result is unclear.

iOS Example

[aButton setAccessibilityLabel:NSLocalizedString(@"Add to favorites video", @"Add to favorites button accessibility label")]; 

iOS Failure

[aButton setAccessibilityLabel:NSLocalizedString(@"Adds this video to your favorites", @"Add to favorites button accessibility label")];

Android

Use the android:contentDescription property to provide short and concise alternatives. The exception is on EditText fields; these must be coded using the android:hint attribute. This helps users understand what content is expected when the text field is empty. When the field is filled, TalkBack reads the entered content to the user, instead of the hint text.

Android Example

<button android:layout_height="wrap_content" android:id="@+id/sunnyday" android:src="@drawable/blue" android:focusable="true" android:contentDescription="Main Menu"></ImageView>  

Android Failure

<button android:layout_height="wrap_content" android:id="@+id/sunnyday" android:src="@drawable/blue" android:focusable="true" android:contentDescription="Exit this screen and return to the main menu"></ImageView>  

HTML

Use the alt attribute to provide alternatives for images. When providing alternatives for input fields via the title attribute ensure the title attribute is concise and does not supply redundant information such as the name or type of the control or obvious instructions such as "enter text here for".

Tip

Title text is not supported on mobile for links but is supported on form inputs.

HTML Example

<!-- image example -->
<img src="/rating.jpg" alt="Rate this article" />
 
<!-- input example -->
<input id="t1" type="text" title="Username" placeholder="username" />  

HTML Failure

<!-- image example -->
<img src="/rating.jpg" alt="Greyed out stars" />
<!-- input example -->
<input id="t1" type="text" title="Enter your username here:" />   

Testing

Procedures Results
  1. Activate a screen reader
  2. Identify any meaningful images, elements, or objects
  3. Verify that an equivalent alternative briefly describes the intent of the functionality
  4. Verify that words such as “image of”, “picture of”, “link to” are avoided

The following checks are all true:

  • Each meaningful image has an alternative that briefly describes the intent and is announced properly
  • Each alternative does not contain words such as “image of”, “picture of”, or “link to”.

Must

Section 508:

  • §1194.21(h)
  • §1194.22(a)

WCAG 2.0:

  • 1.1.1

Animation content must be sufficiently described in audio and/or text

Description.

iOS

iOS description

iOS Example

iOS Example

iOS Failure

iOS Failure

Android

Android description

Android Example

Android Example

Android Failure

Android Failure

HTML

HTML Description

HTML Example

HTML Example

HTML Failure

HTML Failure  

Testing

Procedures Results
  1. Activate the application with an external keyboard. Determine if there are any splash screens, non-system pop-up dialogs, or lightboxes.
  2. Verify the following for all:
    • Ensure they fit on the mobile screen or can be scrolled if needed.
    • Focused when opened on user initiation
    • The Keyboard is navigable.
    • Keyboard access of items behind the modal pop-up is prevented.
    • Can be dismissed via the keyboard.

The following check is true:

  • All content, text, images of text, audio, and video subtitles are announced or displayed in the language set in iOS

Must

Section 508:

  • §1194.21(b)
  • §1194.21(l)
  • §1194.31(a)
  • §1194.31(b)
  • §1194.31(e)
  • §1194.31(f)

WCAG 2.0:

  • 2.1.1

Alternative inputs must be supported

Support for alternative input methods aside from touch must also be supported, this could mean external keyboards or braille displays. Users with disabilities may not be able to operate touch screen interfaces. Alternative forms of input and navigation supported by the platform itself must be supported by the application to facilitate the needs of the user.

iOS

The Accessibility API provides alternative input methods for standard touch events. Focus control to elements is provided via theisAccessibilityElement property - this property should be set to YES to allow accessible input.

iOS Example

[_view setIsAccessibilityElement:YES];   

iOS Failure

[_view setIsAccessibilityElement:NO]; 

Android

Developers must ensure that all active elements can receive focus from assistive technology and alternative input methods. This can typically be accomplished by setting the focusable attribute for the field to true. For editable or read-only custom text elements that are developed by extending standard text elements you must ensure a system caret is set to indicate focus for the element.

Android Example

//A text input field that can be accessed directly by touch and is focusable using the keyboard
<EditText android:id="@+id/editTextP" android:inputType="textPassword" android:layout_height="wrap_content" android:layout_width="wrap_content" android:focusable="true"></EditText>

Android Failure

//A text input that cannot be focused using the keyboard
<EditText android:id="@+id/editTextP" android:inputType="textPassword" android:layout_height="wrap_content" android:layout_width="wrap_content" android:focusable="false"></EditText>

HTML

Any HTML gestures must be supplemented with standard navigation methods such as keyboard focus, key presses, links, buttons, or other controls. For example, a drag and drop operation may be supplemented by select elements allowing the user to choose multiple combinations.

HTML Example

<!-- carousel that supports swiping left and right
touch events such as touchstart, touchend, and touchmove are supplemented with keyboard access using buttons, or by watching key presses. -->
<a href="/...">Previous</a>
<a href="/...">Next </a>

HTML Failure

<!-- Gesture monitoring without equivalent keyboard access -->
<script type="text/javascript">
... // perform some action on touch
</script>
...
<div
  ontouchstart="touchStart(event);"
  ontouchmove="touchMove(event);"
  ontouchend="touchEnd(event);"
  ontouchcancel="touchCancel(event);"
></div>

Testing

Procedures Results
  1. Activate a screen reader and physical keyboard
  2. Identify the active screen objects, elements, and controls
  3. Ensure that all items can be navigated to via alternative input methods
  4. Ensure that the items can be activated via alternative input methods
  5. Activate the item
  6. For items with complex functionality, check for equivalent methods of action support such the arrow keys to instead of swipe up and down gestures to move a slider

The following checks are all true:

  • Objects, elements, and controls can be navigated to via alternative input methods
  • Items can be activated and manipulated via alternative input methods

All color combinations must pass the WCAG 2.0 AA-compliant colour contrast check in accordance with the Snook colour contrast checker.

This is a ratio of 4.5:1 for text 18pt or less in size, and 3:1 for text larger than 18pt or text that is bold and larger than 14pt.

Where it cannot be adapted, stylised text used in pre-existing broadcast logos and branding is exempt from this requirement.

Rationale

If there is sufficient contrast between foreground and background colours, particularly between text and its background but also applicable to the keys of graphs and similar, then users with moderately low vision or with colour deficiencies that affect contrast to a minor degree are more likely to be able to access BBC content without requiring additional assistive technologies.

Techniques

n/a

Tests

Procedure Expected Result Type
Test every foreground and background colour combination against the Snook colour contrast checker Every combination must pass against the WCAG 2.0 AA standard Manual / Tool

All focusable elements must have a clearly identifiable visual style when they have focus

Rationale

Sighted keyboard users do not have the explicit association between pointer and content that pointing device users have, so it is important that they are aware at all times what element currently has focus and which element keyboard interactions will operate on.

The currently focussed element should therefore have a visual style that makes it clearly distinguishable from the surrounding content.

Techniques

Pass:

<style>
    a {
        text-decoration: none;
    }
    a:focus {
        text-decoration: underline;
    }
</style>

Fail:

<style>
    a {
        outline: none;
    }
</style>

Test

Procedure Expected Result Type
For every <a><button>, or other focusable element check the visual style of the:focus state All <a><button>, and other focusable elements must have a visually distinguishable style between their regular and:focus states Manual

Page 16 of 18