TPG Blog

When you build an iOS app it’s easy to make it VoiceOver accessible. Native UI controls have accessibility built-in as standard, and custom controls can be accessibility-enabled without difficulty.

When it comes to testing, there is no substitute for using your app on an iOS device with VoiceOver turned on. When your app (or prototype) is in a fit state to be deployed on a device, testing it with VoiceOver, or better still asking VoiceOver users to test it, will give you realistic feedback.

Accessibility Inspector (available in the iOS Simulator) can then be used to debug any problems you discover. Accessibility Inspector lets you simulate VoiceOver interactions, and examine the accessibility information that’s available for the controls in your app. Accessibility Inspector doesn’t have speech output, so it’s a debugging tool rather than a testing tool. Testing with VoiceOver and debugging with the Accessibility Inspector is a good approach though.

Testing with VoiceOver

You can turn VoiceOver on/off at any time by triple clicking the home button, but the first time it’s a good idea to go to Settings > General > Accessibility > VoiceOver and tap the switch to turn it on. At the same time check that Speak Hints is enabled (it’s on by default). Hints will help you use VoiceOver, and you’ll also want to test any hints included in your app.

When VoiceOver is turned on you’ll need a different set of gestures. The following basic gestures will help you test your app:

Move finger on screen

Causes VoiceOver to announce whatever is under your finger.

Single tap

Causes VoiceOver to announce the selected control.

Double tap

Activates the selected control.

Flick left/right

Moves to the previous/next control.

Three finger swipe left/right

Moves to the previous/next screen.

When you test your app it’s a good idea to simulate the experience of a VoiceOver user as closely as possible. Triple tap to turn the screen curtain on/off. This disables the visual display on the device, letting you explore your app using VoiceOver alone.

Debugging with Accessibility Inspector

To turn on Accessibility Inspector, run your app in iOS Simulator, go to Home > Settings > General > Accessibility and slide the Accessibility Inspector switch to on. This opens the Accessibility Inspector panel.

Accessibility Inspector will remain available until you use the switch to turn it off. However, you can temporarily turn it on/off using the toggle in the corner of the panel (a circle with an X)h.

When you use iOS Simulator you can mimic touch gestures with a mouse. A single click simulates a tap, and scrolling simulates flicking or dragging. With Accessibility Inspector turned on, a different set of gesture replacements is used:

Single click

Selects a control.

Double click

Activates the selected control.

Dragging or flicking can’t be simulated with Accessibility Inspector running. You need to temporarily disable it (toggle the close control in the upper left of the panel), then scroll the mouse to the desired location before enabling Accessibility Inspector again.

In the Accessibility Inspector panel you’ll find two types of information: properties and notifications.

Accessibility properties

You can examine the accessible label, value, hint (if available), accessibility traits and frame co-ordinates for each control. As you update your code the changes are reflected in real time, helping you experiment with different solutions.

Accessibility notifications

Notifications are messages that keep VoiceOver up-to-date with what’s happening in your app. For example, you might use UIAccessibilityAnnouncementNotification to notify VoiceOver users when some information appears briefly on screen.

Used in combination, testing with VoiceOver and debugging with Accessibility Inspector is an effective approach. For example, you might discover an unidentified control during testing. Using the Accessibility Inspector you can examine the control to make sure it has an accessible label and that the relevant traits have been enabled. If you need to make changes to your app you can check them in Accessibility Inspector, before verifying them with VoiceOver in the next release.

Use the Accessibility Inspector in XCode and iOS simulator

A short video tutorial by Ted Drake

Here at the paciello group we are very excited by the improvements being made to our aViewer accessibility API information inspection tool. We want to share the updated aViewer with you and in the process elicit your feedback on the new features and any bugs you may find.

Features

• Exposes MSAA, iAccessible2, ARIA, HTML DOM and UI Automation properties. Note: UIA properties will only be displayed for browsers that support it i.e. Internet Explorer, same goes for IA2 which is supported in FireFox and Chrome, but not IE.
• Displays a navigable accessibility tree. The tree scope can be customized via the ‘view’ menu.
•  Accessibility properties, accessibility tree and HTML code panes.
• Customize which MSAA, IAccessible2 and UIA properties to display via the settings dialog:
  
• Show balloon tip with MSAA, IA2 and HTML code information on element hover, focus or as you navigate the accessibility tree.
  • Information to display in the balloon tip can be customized by using the View (alt+v) menu – ‘balloon tips’ sub menu.
  • 
    Submit button with associated balloon tip displaying MSAA information for the element.
• Customize what to display via the view menu (alt+v):
  

• IAccessible2 relations are  listed in the object information tree view

• What this means is that if an element has an associated label which is associated using the IA2 labelledby relation type (for example, this relation is used extensively in FireFox) or it has any of the ARIA relationship attributes (also supported in FireFox) you can select the relation  target in the tree view and the element it is referenced by will be highlighted in the page:

Screenshot showing a focused element , the listing in aViewer of its labelledby relation and its associated targets. One of the targets listed is selected and the referenced element is highlighted on the page

The aViewer Toolbar

1. Watch Focus (F4) – Information will be displayed for the element that has focus
2. Watch Cursor (F5) – Information will be displayed for the element that is under the cursor
3. Show Highlight Rectangle (F6) – places a visible highlight rectangle around the element that is currently being inspected
4. Show tooltip (F3) – displays tooltip in context with MSSA information (note: accessible name for this button is not currently user friendly)
5. Copy Text to Clipboard (F7) – copies all the information currently displayed to the clipboard
6. Focus Rectangle Only (F8) – disables all features except the keyboard focus rectangle
7. Navigate to Parent Object (F9)
8. Navigate to First Child Object (F10)
9. Navigate to Previous Sibling Object (F11)
10. Navigate to Next Sibling Object (F12)
11. Show Online Help (F1) – opens the Aviewer help in a browser window.
12. Desktop Mode – Disables HTML and ARIA inspection features.
13. Settings –
    1. Modify displayed properties via the check boxes
    2. Change font and size
    3. In order to inspect IAccessible2 information the DLL needs to be registered on initial use.
       1. Register
       2. Unregister

Note: the settings and desktop mode don’t currently have keyboard shortcuts, but can be activated using the keyboard by tabbing to the toolbar then using the arrow keys, then spacebar/enter to enable/disable.

Note: this version does play better with screen readers and  we are working on improvements.

Note: the HTML view works in FireFox and IE, but not Chrome as Chrome not expose the required information.

Issues:

• There are still issues for screen reader users, that we are working on, but we hope this is a step in the right direction.
• When navigating the page content (not via the accessibility tree), the balloon tips can only be displayed using keyboard navigation on focusable elements (any element will display a balloon tips using the mouse). I have created a simple bookmarklet that adds tabindex=0 to every element on a page:
  Add tabindex=0 This can be used by keyboard only users to allow in page navigation of all elements. We will look also at adding this as a feature of aViewer.
• Appears to work better on windows Vista than windows 7, especially with NVDA.

You can try aViewer out on a test page which has includes all the HTML/HTML5 form controls. Note: the level of implementation support for new HTML5 controls varies by browser.

Note: the HTML code view works in FireFox and IE, but not Chrome as Chrome does not expose the required information. In Firefox the code view displays the inner HTML for the currently focused element. In IE it displays the outer HTML for the currently focused element.

Download

Save the file, unzip and select the aViewer.exe.

aViewer 2013 (zip file 1 mb)

Special thanks

To Jun for all his work on aViewer development and to Hans and Gez for feedback.

tl;dr

Adding ARIA landmarks to your existing site, or to a site you are developing, provides useful global navigation features and aids understanding of content structure for users. Over time the necessity of explicitly assigning landmarks will lessen as browsers build in ARIA landmark roles to newer HTML element semantics. There is widespread support for ARIA landmarks in browsers and screen readers.

How ARIA landmark roles help screen reader users

Leonie Watson demonstrates how ARIA landmark roles help screen reader users understand the purpose of different areas of a web page, such as search, navigation or main content.

video on YouTube

ARIA Landmark Roles

The WAI ARIA specification defines a set of specialised “landmark” roles. These roles provide a method to programmatically identify commonly found sections of web page content in a consistent way. they can be used now in whatever flavour of (X)HTML you prefer. This allows assistive technologies to provide users with features which they can use to identify and navigate to sections of page content.

Information about WAI – ARIA landmarks from WAI-ARIA Best Practices (Editors’ Draft 6 August 2010)

Landmarks are a vast improvement over the rudimentary “skip to main content” technique employed prior to WAI-ARIA. If possible it is best to use these as landmarks.
…

The presence of common, semantic, navigation landmarks allows each site to support the same standard and allows your assistive technology to provide a consistent navigation experience – an important feature for screen readers and alternate input solutions. For users with cognitive and learning disabilities the landmark information could be used to expand and collapse these regions of your page to aid in simplifying the user experience by allowing the user to manage the amount of information processed at any one time.

There are also mainstream benefits of providing navigation landmarks. Your browser may assign key sequences to move focus to these sections as they can be set on every site. Navigation to these landmarks is device independent. A personal digital assistant (PDA) could assign a device key to get to them in your document.

How to use landmark roles

It is a painless process to add landmark roles to existing (and new) pages. Simply add a role attribute to a container element, using the most appropriate role value for the content of the container, for example:

<main role="main">

• An example page with ARIA landmark roles
• A list and descriptions of landmark roles is available in Table 1

Please note:

Probably the most important rule for applying landmarks is to ensure all content resides in a landmark region to ensure no content is orphaned. This way a screen reader user can safely use landmark navigation without missing content.

Rich Schwerdtfeger

Adding Landmark Roles to WordPress

I added them to the TPG blog (uses WordPress) in about 20 minutes, it involved the editing of the following WordPress files: sidebar.php (added complementary, navigation (x2) and search landmarks), header.php (added banner landmark), single.php (added main landmark), footer.php (added contentinfo landmark) & index.php (added main landmark). The results can be visualised using The Juicy Studio Accessibility Toolbar document landmarks feature:

Support for Landmark Roles

Landmark roles are supported in JAWS, NVDA, ORCA, Chromevox, Window Eyes and VoiceOver and via a FireFox addon for keyboard users.

Landmark Support behaviour in JAWS version 10 and above

For JAWS version 10 and above, landmark keyboard navigation in virtual mode is:

• next landmark ; (semi-colon)
• previous landmark SHIFT + ; (semi-colon)
• list landmarks CTRL + INS + ; (semi-colon)

When cycling through landmarks using the semi-colon key, the landmark role name +”landmark” is announced. A user can then cursor (down arrow key) to the content. If a landmark is a container for other landmarks it is not included within the cycle order, but is included within the list order. By default the list does not display nested landmarks, but when a nested landmark container item receives focus, it is announced to the user that the list item is closed, informing the user that the item has sub items. A user can then use the right arrow key to open the sub list.

ARIA Landmark Role Tests

Detailed information about current assistive technology support can be found in the accompanying document ARIA Landmark Role Tests (November, 2011).

What about the new Sectioning Elements in HTML5

The new sectioning elements in HTML5 have some overlap with ARIA landmark roles, but in a majority of cases there is no equivalent for the ARIA landmark roles in HTML5. It is suggested that where there is a similarity the ARIA roles can be used to provide semantic identification that has a practical use now, for example if you want to use the HTML5 nav element, add role="navigation" to it, so supporting Assistive Technology (AT) can convey the semantic information to users. When HTML5 elements such as nav are supported by AT, you can then remove the role as it will no longer be required.

<nav role="navigation">

For an example of the use of HTML5 elements and ARIA landmark roles have a look at code of Bruce Lawson’s site.

Comparison of ARIA landmark roles and HTML5 structural elements ARIA Landmark Role HTML5 Sectioning Element role="application" Represents a region of the page representing a unique software unit executing a set of tasks for its users. It is an area where assistive technologies should also return browse navigation keys back over to the web application in this region.
note: It is strongly recommended that role="application" be used very sparingly. Refer to Using role="application"
No HTML5 element equivalent.
Recommend using on a semantically neutral element such as a div.
role="banner" A region that contains the prime heading or internal title of a page. Most of the content of a banner is site-oriented, rather than being page-specific. Site-oriented content typically includes things such as the logo of the site sponsor, the main heading for the page, and site-specific search tool. Typically this appears at the top of the page spanning the full width.
Note: Within any document or application, the author SHOULD mark no more than one element with the banner role. No HTML5 element equivalent.
Recommended to be used on one header element per page if the header element is used as described for role=”banner”. role="complementary" A supporting section of the document that remains meaningful even when separated from the main content.There are various types of content that would appropriately have this role. For example, in the case of a portal, this may include but not be limited to show times, current weather, related articles, or stocks to watch. The content should be relevant to the main content; if it is completely separable, a more general role should be used instead. <aside> The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography. role="contentinfo" Metadata that applies to the parent document.For example, footnotes, copyrights, and links to privacy statements would belong here.Note: Within any document or application, the author SHOULD mark no more than one element with the contentinfo role. No HTML5 element equivalent. Recommended to be used on one footer element per page if the footer element is used as described for role=”contentinfo”. role="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. Recommend using on a semantically neutral element such as a div or on a form element, if the form element role="main" The main content of a document. This marks the content that is directly related to or expands upon the central topic of the document. Within any document or application, the author SHOULD mark no more than one element with the main role.
Note: Within any document or application, the author SHOULD mark no more than one element with the main role. The main element represents the main content of the body of a document or application. The main content area consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. role="navigation" A collection of navigational elements (usually links) for navigating the document or related documents. The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. role="search" The search tool of a web document. This is typically a form used to submit search requests about the site or to a more general Internet search service. No HTML5 element equivalent.
Recommend using on a semantically neutral element such as a div or on a form element, if the form contains only search related controls and instructions.

Role and element descriptions from:

• WAI-ARIA 1.0 draft specification
• W3C HTML 5.1 draft Specification

Further reading:

 

• Usable landmarks across desktop and mobile
• Latest ARIA landmark support data (2011) note support was widespread 2 years ago and has improved since!
• HTML5 Accessibility Chops: ‘real world’ ARIA landmark use
• Using ARIA in HTML

I am honoured and excited to say I am now a member of the W3C HTML editors team. Joining Robin, Erika, Silvia, Ted and Travis to work on continuing the development of HTML.

What does this mean?

In practical terms it means I have write access to the HTML specification on Github. This does not mean I, or any of the editors, can change HTML at will. It does mean I have a little more opportunity to effect change upon the development of the HTML language in accordance with the agreed upon processes of the HTML Working Group. It primarily means a bucketload of work in the form of responding to and resolving bugs.

Recent discussions and changes:

• Discussion which lead to a minor change in the information in the HTML spec about using the figure element.
• Discussion which lead to some minor changes in the information in the HTML spec about using main element.
• Resolved a bug which resulted in the addition of a section about Captcha Images to HTML 5.1

Note: all of the above changes are preliminary changes to the HTML 5.1 editor’s draft and subject to change based on feedback and future decisions of the HTML working group.

Working together

The development of the HTML standard is a collaborative effort and it is important that the voices of users and developers, as well as implementers, are heard and taken into account.

You can provide input in a number of ways:

• Join the HTML Working Group
• Comment via the HTML Public comments list
• File a bug on the HTML spec (requires registering for a bugzilla account – its simple!)
• Dropping into #HTML-WG IRC and chatting, it’s logged.

I  also follow discussions on blogs such as HTML5Doctor.com and bring up HTML related discussions to the working group’s attention.

You can keep up with changes to the spec on twitter via @HTML_commits. You can also ping me on twitter : @stevefaulkner

tl;dr

If you are an HTML author or developer – use the HTML 5.1 Nightly edition of the HTML specification.

What is this thing called HTML?

It can be confusing, authors and developers now have a seeming multitude of authoritative sources for the definition of how HTML features work and how HTML features are to be used.

Why use the HTML 5.1 Nightly?

It is updated regularly (as the name implies) with the latest new features, bug fixes and editorial changes cherry picked from a range of sources, primarily but not exclusively from the WHATWG spec.

Why a range of sources?

The development of many new features occurs via the WHATWG as it is the venue of choice for some (but not all, while all browser implementers are members of the W3C). Development of new features also occurs at the W3C (the main element for example) and other organisations. While the HTML WG liaises with the WHATWG and other organisations, the content of the HTML specification is decided by the HTML working group which reviews and works towards technical consensus before adding/modifying features or changing advice  and requirements in HTML, whatever the source. If new features are considered controversial, not fully baked, are better defined as a module, or there are multiple proposals for solving similar use cases, they may be developed as HTML extension specifications. This provides all stake holders an opportunity for review and discussion of the features.

HTML is not just for browser implementers

From a user’s and developer’s point of view, how to use HTML and how it should be used are important considerations as its use directly impacts those who consume the semantic and structural information and  interaction behaviours that HTML as implemented (or not) provides.

The HTML specification – authoring advice and requirements

The HTML specification provides authoring advice and requirements; developers use this and authors of books and articles on HTML use it to inform their writing. The HTML 5.1 Nightly version of the specification includes the most up to date authoring advice and requirements, which is actively developed, primarily within the HTML working group  Unlike for the implementation aspects which are primarily dictated by browser vendors, the voices of users, developers and accessibility communities are important sources for deciding what the HTML specification has to say about how HTML should be used.

Further Reading:

Plan 2014 – for an understanding of what is happening with HTML and beyond

Some current discussions on the HTML WG list:

• 4.13.1 Bread crumb navigation – use of right angle brackets
• Current definition of <figure> in HTML is problematic
  • This topic is also being discussed on the WHATWG list
• Document Outlining issues
• Is the current definition of the article element in HTML useful?
• <article> in one-article document (was Re: Staged bugs & editorial fixes for HTML5.0, and staged WHATWG patches for HTML5.1)