Using aria-describedby to provide a long description link on an image

ARIA aria-describedby attribute used on HTML image element and pointing to HTML a element makes the image accessible to expose showlongdesc action. This action opens an URL provided by @href attribute on HTML a element in a new window.

When the image has focus the screen reader user can press enter to activate the link, because a link action showlongdesc is exposed on the image, it uses the URL from the link referenced via aria-describedby.

code:

Note: example from the test page.

<figure>
<img src="shalott.jpg" aria-describedby="a" alt="Painting of a  young woman with long hair, sitting in a wooden boat.">
<figcaption>
A painting inspired by Alfred Tennyson's poem The Lady of Shalott.
</figcaption>
<p><a id="a" href="http://www.tate.org.uk/art/artworks/waterhouse-the-lady-of-shalott-n01543/text-summary">Further information about the painting.</a></p>
</figure>

Notes:

• This is an experimental implementaion only I DO NOT suggest anyone uses this method for anything other than testing.
• Only works in FireFox 14+
• Although the accessible action is exposed and can be activated from the image when using a screen reader (when virtual focus is on the image, pressing enter will open the link), there is no indication to user that the link can be activated from the image.
• From initial discussions with implementers and stakeholders, they are not keen this implementation
• Still works when the link is hidden using the HTML5 hidden attribute or CSS display:none
• Has the same UI issue as current longdesc attribute implementations: The link always opens in a new window/tab.
• test page

New features

• Exposes 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.
• the Accessibility properties, accessibility tree and HTML code panes are now collapsible.
• Customize which MSAA, IAccessible2 and UIA properties to display via the settings dialog:
  
• Show tooltip with MSAA information on element hover, focus or as you navigate the accessibility tree:
  
• Customize what to display via the view menu (alt+v):
  

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 – 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 checkboxes
    2. Change font and size
    3. In order to inspect IAccessible 2 information the DLL needs to be registered on initial use.
       1. Register
       2. Unregister

Note: the settings, tooltip 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.

Caution

This is an alpha version and may crash and be generally buggy. Please provide feedback, thanks!

Note: this version does not currently play well with screen readers we are working on this.

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

Download

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

aViewer 2012 alpha (zip file 576 kb)

Special thanks

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

The standard technique for hiding content for all users has been the use CSS display:none. Now, both ARIA and HTML5 also provide a semantic indication of content state that indicates content is hidden or should not be available to users:

HTML5 hidden

The HTML5 hidden attribute provides a semantic indicator:

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified.

Example code:

<p hidden>This content is hidden.</p>

HTML5 hidden effects:

• In supporting browsers the content is not displayed to any user.
• semantic indicator of state in HTML code (hidden attribute)
• CSS style of display:none applied by browser.
• Focusable content is not included in tab order.
• Not included in the accessibility tree.

aria-hidden

Indicates that the element and all of its descendants are not visible or perceivable to any user as implemented by the author.

Example code:

<p aria-hidden="true">This content is hidden.</p>

<p aria-hidden="false">This content is not hidden.</p>

aria-hidden effects:

• In supporting browsers in conjunction with supporting assistive technology the content is not conveyed to the user via the assistive technology.
• Content is displayed in the browser.
• semantic indicator of state in HTML code (aria-hidden attribute)
• In some browsers its not included in the accessibility tree in other browsers it is included in the accessibility tree.
  • For browser that include aria-hidden content in the accessibility tree focusable content is included in tab order and is navigable and operable for AT users (as well as other users).
• In browsers that do include the content in the accessibility tree the content has an accessible MSAA (if supported) state of invisible. If IA2 is supported aria-hidden=true is passed as an object attribute. If UIA is supported aria-hidden=true is passed as an ARIA property.
• aria-hidden=false is not mapped in any browser that supports aria-hidden, thus its use has no meaning or in other words has the same meaning as its absence.

CSS display:none

As mentioned, the standard method to hide content from all users in browsers that support CSS is and has been to use CSS display:none.

Example code:

<p style="display:none">This content is hidden.</p>

display:none effects:

• In supporting browsers the content is not displayed to any user.
• Focusable content is not included in tab order.
• Not included in the accessibility tree (except for IE)
• In IE the content has an accessible MSAA (if supported) state of invisible.  If UIA is supported OffScreen=true.

Recommendations:

Hiding content from all users

If you want to hide content from all users, use the HTML5 hidden attribute (along with CSS display:none for browsers that do not yet support hidden) There is no need to use aria-hidden.

Example code:

.hidden {display:none}

<p hidden class="hidden">this content is hidden from all users</p>

Hiding non interactive content from visible display

Use an off screen technique to remove content from visible display, but still available to screen reader users:

Example code:

.offscreen
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}

<div class="offscreen">This text is hidden.</div>

Modified example code from: WebAIM – CSS in Action: Invisible Content Just for Screen Reader Users

Hiding interactive content from visible display

Hiding interactive (focusable) content from visible display using the off screen technique means it is not visible, but still  in the tab order and causes issues for keyboard only users. Focusable content should only be hidden from visible display if the focusable element becomes visible when it recieves focus:

Example code:

a.offscreen
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}

a.offscreen:focus
{position:relative;
left:0px;
width:auto;
height:auto;
overflow:auto;
}

<a class="offscreen" href="test.html">this link is offscreen unless it has focus</a>

Notes by Ted Drake, on use of the off screen technique described:

Using negative position can create long scroll bars when localizing a site for a rtl language. Also, it uses CSS properties that are commonly used and easy to accidentally over-ride.

The Yahoo Accessibility Lab recommends using clip for content that should be hidden from the visual user, yet available to screen reader users. Thierry Koblentz has a great article on this technique, as well as the underlying philosophy behind using the correct CSS techniques for hiding content. Clip your hidden content for better accessibility

The tests

Support for aria-hidden, HTML5 hidden and the off screen technique was tested using JAWS, Window Eyes and NVDA (Windows), ChromeVox (Chrome OS), VoiceOver (iOS and Mac OSX) and Orca (Linux) with supporting browsers for each OS.

Result summary

• Use of HTML5 hidden (+ CSS display:none) worked in all screen reader/browser combinations tested.
• Use of the off screen technique worked in all screen reader/browser combinations tested.
• Use of aria-hidden=true worked in some screen reader/browser combinations tested.
• Use of aria-hidden=false had no effect in any of the screen reader/browser combinations tested. In other words if content is hidden from all users using HTML5 hidden or display:none applying aria-hidden=false to the content does not make it visible to screen reader users.

Detailed tests and test results are available.

further reading:

Providing Context for Ambiguous Link Phrases

killing CSS outlines for mouse users only

Note: I am not advocating removal of CSS outlines, but if you must, do it in a way that does not screw keyboard users

The problem

Some developers/designers/clients do not like the default focus rectangle that is displayed when a user clicks on an interactive element such as a link. Methods to remove it such as onfocus="blur()" result in keyboard users being unable to interact with the link or control. While use of CSS outline:none results in the link or control being focusable but with no visible indication of focus for keyboard users. Neither method provides an accessible user interface.

An accessible solution?

Starting with the page having no CSS outline:none rules applied. Apply CSS outline:none rules using JavaScript ONLY IF mouse user depressesing the mouse button is detected. Remove the rules again IF keyboard interaction is detected.

Example code:

Notes:

• A test page is available
• Example only suppresses outline on links for mouse users.
• Tested with Firefox, IE, Chrome, Opera and Safari on Windows.
• Use of inline event handlers is for demonstration purposes only.
• If you create a more sophisticated script based on this idea please share
  • Aireh Glazer has created a Cross-Lib accessible outline removal script
  • Lindsay Evans has created outline.js
• If you encounter any issues provide feedback
• how it works with touch based interfaces has not been investigated much:
  • using Opera mini and Safari on iPad, the links still show their default activation indicator and the same using webkit on android (feedback from @sideshowbarker), which is the best outcome for usability/accessibility.

The back story

The W3C HTML5 specification now states:

element . blur()

Unfocuses the element. Use of this method is discouraged. Focus another element instead. 

Do not use this method to hide the focus ring. Do not use any other method that hides the focus ring from keyboard users,in particluar do not use a CSS rule to override the ‘outline’ property. Removal of the focus ring leads to serious accessibility issues for users who navigate and interact with interactive content using the keyboard.

The WHATWG Living Standard makes claims it provides advice on how to remove focus outlines in an ‘accessible manner’:

The W3C HTML specification omits some advice about how to remove focus outlines in an accessible manner (instead only urging authors not to remove them without giving an alternative to address the “they’re ugly” use case), because of a working group chair decision from March 2012.

The WHATWG HTML living standard continues to state:

element . blur()Unfocuses the element. Use of this method is discouraged. Focus another element instead.

Do not use this method to hide the focus ring if you find the focus ring unsightly. Instead, use a CSS rule to override the ‘outline’ property. (Be aware, however, that this makes the page significantly less usable for some people, especially those with reduced vision who use focus outlines to help them navigate the page.)

For example, to hide the outline from links, you could use:

:link:focus, :visited:focus { outline: none; }

The WHATWG HTML living standard does not contain advice on how to remove focus outlines in an ‘accessible manner’

By its own admission the ‘living standard’ states the recommended alternative to using .blur() is bad for accessibility:

Be aware, however, that this makes the page significantly less usable for some people, especially those with reduced vision who use focus outlines to help them navigate the page.

Note: This warning also contains a factual innacuracy as use of outline:none makes the page significantly less accessible to any keyboard only user, not only those with reduced vision. Not providing a visible indication of focus makes the user interface unusable for keyboard only users in any circumstance where the page has more than a few focusable elements.

ARIA role=banner usage

As per the ARIA specification there should only be 1 role=banner per page. Of the 93 pages found to include the banner role:

• 90 pages had 1 instance (97%)
  
• 2 pages had 2 instances
• 1 page had 4 instances

ARIA role=main usage

As per the ARIA specification there should only be 1 role=main per page. Of the 130 pages found to include the main role:

• 124 pages had 1 instance (95%)
  
• 1 pages had 2 instances
• 1 page had 3 instances
• 1 page had 4 instances
• 1 page had 7 instances
• 2 pages had 10 instances: The daily What & fail blog which look to be affiliated sites using the same template.

ARIA role=contentinfo usage

As per the ARIA specification there should only be 1 role=contentinfo per page. Of the 72 pages found to include the contentinfo role:

• 69 pages had 1 instance (96%)
  
• 1 pages had 2 instances
• 1 page had 2 instances
• 1 page had 26 instances
• 1 page had 72 instances

Other analysis:

• There was found to be a high correlation between use of the ARIA landmark roles  and use of the HTML5 doctype. For example of the 130 pages containing role=main, 101 (78%) also used the HTML5 doctype.
• Typically role=main was included on a div element and there was a high correlation between use of role=main and id values such as “main” (39 instances) and “content” (34 instances).
• role=”contentinfo” was used in conjunction with the footer element on 36/69 (52%) of instances.
• role=banner was used in conjunction with the header element on 41/93 (44%) of instances.
• The use of any landmark roles across the 8900 or so sample pages was low (approx. 3%), but use was considerably higher (17%) on the subset of pages (1539) that used the HTML5 doctype.
• role= search was found on 103 pages, 90 had 1 instance, 13 had 2 instances.
• role=application was found on only 5 pages, which is a good result considering the issues that can arise through its misuse.

Conclusion

From an initial analysis the correct use of ARIA landmark roles is surprisingly high. Developers are generally using ARIA landmark roles as intended. Although use is low, there is an major upward trend in use as sites switch to HTML5.

Further reading:

• Latest ARIA landmark support data
• HTML5 Accessibility Chops: data for the masses
• HTML data for the masses: DOCTYPE usage
• Using WAI ARIA Landmark Roles – updated

1. Check current page using the W3C Nu Markup Validation Service (can check local/behind firewall pages as long as there is an Internet connection)
   1. check using page DOCTYPE
   2. check using page DOCTYPE (in a new tab/window)
   3. check using HTML5 DOCTYPE – overrides page doctype
   4. check using HTML5 DOCTYPE – overrides page doctype(in a new tab/window)
   5. Filter Validation results (shows only results relevant to WCAG 2.0 success criterion 4.1.1 Parsing) selecting this on the results page of the W3C Nu Markup Validation Service will filter out any errors not relevant to the WCAG 2.0 parsing criteria. (Refer to: WCAG 2.0 parsing error bookmarklet for more details.)
2. Open in other browsers: This feature replaces the Firefox and Opera buttons on the previous WAT version. It allows you to add any browser you have installed. Once added the browsers will show in the list and you can open the current page open in IE, in the selected browser.

WAT 2012 Download

Web Accessibility Toolbar 2012 (2mb)

Top 10000 web sites home pages HTML code data dump

Searches on the HTML of the 8900 sample pages were conducted on various HTML elements and attributes.

NOTE: the resulting data output files are sometimes large and the HTML code is whoeful, they are supplied as. I will as time permits analyse the data and also clean up the HTML code.

further reading:

• HTML5 Accessibility Chops: data for the masses
• HTML data for the masses: DOCTYPE usage

Total pages with a doctype declaration: 7708

• XHTML 1.0: 4930 – 55%
• HTML5: 1539 -17%
• HTML 4.01: 960 – 11%
• XHTML 1.1: 111 – 1.3%
• HTML 4.0: 96 – 1%
• XHTML+RDFa: 24 -0.3%
• HTML 3.2: 9 – 0.1%
• html SYSTEM: 9 – 0.1%
• XHTML Mobile: 4
• html 2.0: 1
• other: 34 – 0.4%

doctype data text file (zip 5k)

DOCTYPE’s and Accessibility

To my knowledge the use of any particular DOCTYPE has absolutely no effect upon the accessibility of the associated HTML code. What is important is that the doctype you use does not trigger browser quirks mode. The simplest doctype to use to ensure that quirks mode is not triggered is the HTML5 doctype:

<!DOCTYPE html>

For data set and other details refer to: HTML5 Accessibility Chops: data for the masses

Top 10000 HTML files zip file – 121 MB (Please only download if you are going to make use of the data)

hgroup element usage

I have only just started to analyse the data. The first analysis is of the new HTML5 hgroup element and this is as yet only a simple gathering of instances of its use. No attempt has been made as yet, for example, to analyse what percentage of its use conforms to HTML5 author conformance requirements.

Of the top 8915 HTML pages, 79 (0.89%) were found to include use of the HTML5 hgroup element. A total of 418 instances of the hgroup were found within the 79 pages.

Instances of hgroup element use in top 10000 web sites – home pages

Inclusion of hgroup in HTML5

Note: I am a proponent of the removal and/or replacement of hgroup in HTML5, there are currently 5 change proposals being reviewed by the W3C HTML working group chairs on this subject:

1. Change Proposal: replace hgroup with the subline element
2. Change Proposal: no-change hgroup
3. Change Proposal: replace hgroup with a simple element
4. Change Proposal: remove hgroup add an outlineMask attribute
5. Change Proposal: Replace <hgroup> with an element that has a simple content model and backwards compatibility.

Blind Ambition Plea for Funds to Keep Free Software Project Alive

NVDA is perhaps the cream of the crop when it comes to web accessibility for blind users. The user experience is equally terrific. TPG uses NVDA as part of it’s quality assurance testing for all web properties. In short, we need to do something to “Save the NVDA” so to speak. Spark a campaign if you will.

Having said that, my general interest involves platform support, specifically desktop and mobile. I’ve read the product specification. Still, I’d like to get the inside scoop from the user community.

I’d like to reach out to the general community (not to mention Mick and Jamie!) to get a better sense of the user experience. Would you be kind enough to respond to this blog and share your thoughts?

Thanks!