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).

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

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:

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.

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

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

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

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)

If you have a disability, are a mobile user and have 5 minutes to spare please take a moment to fill out this online survey on mobile accessibility hosted by the The Paciello Group (TPG).

The data gathered will be a useful insight into mobile usage and help us  inform mobile accessibility strategy and development.

Obviously the more people filling it in the better to please pass this on to any other mailing lists, blogs or lists you might feel appropriate.

Thanks to @iheni for the words!

If you want to hide content from mobile and tablet users as well as assistive tech users and keyboard only users, use the title attribute.

The details

The HTML title attribute is problematic. It is problematic because it is not well supported in some crucial respects, even though it has been with us for over 14 years. With the rise of touch screen interfaces, the usefulness of this attribute has decreased. The accessibility of the title attribute has fallen victim to a unfortunate combination of poor browser support, poor screen reader support and poor authoring practices.

Situations in which the the title attribute is not useful due to lack of support:

• Displaying information for web content viewed on mobile phone browsers. Typically in desktop browsers title attribute content is displayed as a tooltip. From what I could find, tooltip display is not supported in any mobile browser and alternative visual methods of accessing title attribute content are not supported.
• Providing information for people who cannot use a mouse. Typically in desktop browsers, title attribute content is displayed as a tooltip. Although the tooltip behaviour has been supported for 10+ years, no browser as yet has implemented a practical method to display title attribute content using the keyboard.
• Using it on most HTML elements to provide information for users of a variety of assistive technologies. Access to title attribute information is not supported uniformly by screen readers

User groups not well served by use of the title attribute

• Mobile phone users.
• Keyboard only users.
• Screen magnifier users.
• Screen reader users.
• Users with fine motor skill impairments.
• Users with cognitive impairments

Examples of title attribute use that are USEFUL:

• Labelling frame or iframe elements:
  • <frame title="navigation">
• Providing a programmatically associated label for a control in situations where a visible text label would be redundant:
  • <input type="text" title="search"> <input type="submit" value="search">
  • labelling controls in data tables.

Examples of title attribute use that are NOT USEFUL or are of LIMITED USE:

• For additional information not provided as text in a link or surrounding content:
  • <a href="newsletter.PDF" title="PDF file, size 1 mb.">newsletter</a>
  • Instead include such information as part of the link text or next to the link.
• Providing the same information provided as link text:
  • <a href="newsletter.PDF" title="newsletter">newsletter</a>
  • Recommend not duplicating content of a link in the title attribute. It does nothing and makes it less likely if people can access title attribute content that they will do so.
• For a caption on an image:
  • <img src="castle1858.jpeg" title="Oil-based paint on canvas. Maria Towle, 1858."
alt="The castle now has two towers and two walls.">
  • Presumably caption information is important information that should be available to all users by default. If so present this content as text next to the image.
• For a label on a control that has no visible text label:
  • <input type="text" title="name">
  • Screen readers users will have access to the control label, as the title attribute is mapped to the accessible name property in accessibility APIs (when a text label using the label element is not supplied ). Many other users will not. Recommend including a visible text label whenever possible.
• Providing the same information as a visible explicitly associated text label for a control:
  • <label for="n1">name</label> <input type="text" title="name" id="n1">
  • Repeating the visible label text does nothing except possibly add cognitive noise for a range of users. Do not do it.
• Providing additional instructions for a control:
  • <label for="n1">name</label> <input type="text" title="Please use uppercase." id="n1">
  • If the instructions are important for using the control correctly, then provide them in text near the control, so they can be read by everyone.
• Expansion of an abbreviation:
  • <abbr title="world wide web consortium">W3C</abbr>
  • The title on the abbr element is well supported by screen reader software, but its use is still problematic, as other user groups cannot access the expansion. It is recommended that the expanded form of an abbreviation is provided in plain text when it is first used in a document, and/or a glossary of terms that provides the expanded form is provided. This is not to suggest that that the expansion should not be provided using the title attribute, only that due to its limitations, an expansion in plain text should also be provided.

HTML 5.1 includes general advice on use of the title attribute:

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to apear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

source: HTML 5.1 – the title attribute

Use of the title attribute in place of an alt attribute on an img element or for an image caption is prohibited

Relying on the title attribute is currently prohibited as many user agents do not expose the attribute in an accessible manner…

source: HTML 5.1

Further Reading

• title attribute use and abuse
• The title attribute – what is it good for? (resurrected)
• Too much accessibility – TITLE attributes

home page accessibility – updated 05/02/13

language – fixed 06/10/12

The UK home page has a lang=”de” on the HTML element. This results in the page being pronounced using the German language setting in JAWS and NVDA.

Suggest they need to use the correct lang value: lang=”en”

<html lang="en">

search form – not fixed 05/02/13

The search form has a pseudo list box which displays the search choices and seach term matches.

It’s keyboard accessible via up/down arrow keys, but the presence of the list is not exposed to assistive technology, users will have no idea it is there.

Suggest, using ARIA to provide correct role, name, state and property information.

An example of a more usable autocomplete widget.

Search dropdown list with search term and search scope options

Use of ARIA roles to identify navigation links as a menu – not fixed 05/02/13

Microsoft navigation links 'security' menu

Code snippet from the navgation links menu:

<ul role="menu" bi:parenttitle="t1">
 <li role="menuitem">
<a href="http://www.microsoft.com/security/default.aspx"
bi:index="0" bi:cpid="hpMenu">Security Home</a></li>
 ...
 </ul>

First thought is, even if marked up correctly, it would be better not to identify the navigation links menu as a menu with menu items as they are a list of links in a web site not a menu in a web application. Adobe have also recently implemented a new navigation menu, it uses a hybrid keyboard interaction approach: tab and up/down arrow with minimal, but effective use of  ARIA to indicate the presence of sub menus to AT users and interaction hints for keyboard only users. It is suggested that Adobe’s approach is more fitting to the context in which it is used.

The Microsoft menu bar does not work as it should. If interactive content is marked up as a menu bar with menus and menu items, its interaction behaviour should be that of a menu bar, it is not. The role information provided via ARIA indicates an expected and defined set of keyboard interactions. The ‘menu bar’ on the Microsoft home page has none of these.

If you test it with a screen reader, you will find a few issues…

Example of a menu bar widget that is suitable for a web application setting (in an embedded HTML editor, for example) and works as it should.

Suggest implementing a navigation links menu that provides appropriate semantics and works for keyboard and AT users.

ARIA landmark use – not fixed 05/02/13

The Microsoft home page, makes use of the ARIA search, navigation and contentinfo landmark roles, but for some unknown reason does not provide a role=main…

Suggest adding role=main.

<div class="grid-container" role="main">
...
</div>

HTML5 use

Uses the HTML5 doctype, section, header and footer elements and input type=search. These have minimal effect on accessibility as support for these elements is somewhat limited. The positive effect of using the HTML5 doctype is that when validating the HTML code ARIA use is not flagged as an error (maybe in this case it should be).

Conclusion

Surprised that user testing was not conducted, or if it was… Come on Microsoft you can do better. Note that this is no way an exhaustive list of issues.

FireFox and Safari still lead the pack

I have completed another round of testing of HTML5 accessibility support in browsers on Mac and Windows. FireFox on Windows and Safari on Mac OSX still have continue to hold very solid leads on the other browsers tested. Chrome and Internet Explorer on Windows have made improvements in their support in the latest version, but are still under 50%:

Internet Explorer suffers and Chrome lags

Internet Explorer suffers because it does not implement any accessibility semantics for structural elements such as article and aside. It’s a mystery why the default implict ARIA semantics are not being conveyed via UI autumation in IE10 for elements that have no native UI automation roles? Its accessibility implementation of new HTML5 controls and audio and video elements meanwhile, is very good! Refer to Notes on HTML5 accessibility support in IE 10 for more details.

FireFox has caught up with IE in terms of canvas accessibility support. Chrome has started to implement canvas element sub-DOM accessibility support, but its limited to keyboard operability at this time, no semantics of the sub-DOM are exposed. Chrome’s mainstream HTML5 implementation continues to outstrip its accessibility support implementation on both Mac and Windows, it appears that Google are not committing enough resources to implementing accessibility in chrome…

Support information for Opera on Windows and Mac and Safari on Windows is not be updated as there appears to be no active effort to implement accessibility in these browsers.

Internet Explorer 10 on Windows 8 meanwhile, includes implementation of a number of new HTML5 features and improved accessibility support for other features.

new HTML5 feature accessibility support in IE 10

The progress element

Default display of the progress element in IE 10 on Windows 8

code example

<progress  value="30" max="100">30%</progress>

As implemented the progress element exposes the appropriate accessibility information via the MSAA and UI automation accessibility APIs.

input type=range

Default display of input type=range (slider) element in IE 10

code example

<input type="range" max="11" min="0" value="7">

As implemented the input type=range element exposes the appropriate accessibility information via the MSAA and UI automation accessibility APIs. It supports operation with the keyboard using the up/down/left/right arrow keys (incremental) or via the home and end keys (minimum/maximum).

current value is displayed as a tooltip when the user drags the slider thumb with the mouse

As illustrated above, a tooltip is displayed displaying the current slider value, but only when using a mouse, not when using the keyboard.

The datalist element

Default display of the datalist element in IE 10

code example

<input type="text" list="mylist">

><datalist id=”mylist”>
<option value="Miss" label="Miss"></option>
<option value="Mr" label="Mr"></option>
<option value="Ms" label="Ms"></option>
<option value="Mad Professor" label="Prof"> </option>
</datalist>

As implemented the datalist element when associated with a text input , turns it into a ComboBox. It exposes some of the appropriate accessibility information via the MSAA and UI automation accessibility APIs. The presence of the list is not indicated via the role, state or properties of the input element, but the list and list items are exposed correctly. It supports operation with the keyboard: the list is displayed when the text input receives focus, the up/down arrow keys can be used to navigate the list items and the enter key selects a list item. A quick test with Narrator (built in Windows 8 screen reader) did not reveal any information being announced about the list or the list item and no indication about the presence of the list.

the required attribute

A message is displayed when a user submits a form without filling in required fields.

code example

<input type="text" required>

The required attribute is supported for visual users only. When an input that is required is not filled in by a user and the form is submitted, a red border appears around the input and a message is displayed (side note: the message is built using SVG). Note further, this occurs for each input that is in error, not only for the first input in the form, which is the current (not very useful) behaviour for other browsers that support required by displaying a message (e.g. Opera and FireFox). There appears to be no accessibility information reported via either MSAA or UI automation. A quick test with Narrator did not reveal any information being announced about required fields or their state.

the audio element

audio element user interface

code example

<audio controls></audio>

The audio element has full keyboard and accessibility information support including accessible name, description, and accessKey information. Each control can be navigated to and operated using the keyboard.

Accessibility tree representation of the audio element in IE 10

the video element

video element user interface with volume slider displayed.

code example

<video controls></video>

The video element has full keyboard and accessibility information support including accessible name, description, and accessKey information. Each control can be navigated to and operated using the keyboard. Note the volume slider is represented in the accessibility tree, but is activated by focusing on the mute button then using the up/down arrow keys to modify the volume level.

Accessibility tree representation of the video element in IE 10

The placeholder attribute

The placeholder attribute value is used as the accessible name for the control if no other accessible name is provided. So from the placeholder attribute test page, only in the first test is the placeholder text used, otherwise it is not exposed in the MSAA or UIA accessibility APIs.

code example

<input type=text placeholder="poot">

Conclusion

Microsoft are doing things well in many respects, but there are gaps.  I particularly like the audio and video implementations which make it much easier for keyboard users to operate the controls without having to remember keyboard shortcuts. It is unfortunate though that each browser that supports accessibility and supports the placeholder attribute has implemented its use in accessible name calculation differently, its a an interoperability nightmare for developers and users.