Accessibility &ARIA 09 Apr 2009 09:59 am
Augmenting Button Text with ARIA
Say you have a set of invitations to connect to colleagues in your favorite social networking software. These might be listed one after another with an accept and reject button associated with each request. But, if someone is using a screen reader to just tab through the buttons on the page, how would you know which button is associated with each invite? Certainly the designers are not likely to want to put the user name within the button text, so how can we make this easier for the person using a screen reader or screen magnifier to access the page?
There are several different ARIA properties you could use. I created a sample page using 4 different strategies aria-labelledby, aria-describedby, aria-label, and the title attribute. See Augmenting Button Text with ARIA. I’ve included code snippets so you can see exactly how the techniques were implemented.
The first approach was to use aria-labelledby to label the button using text containing the associated user name placed within a span that is placed offscreen using CSS. Since the text is positioned offscreen it will not be seen but will be spoken by the screen reader. This seems to work the best with the various screen readers and ARIA supported browsers. However, it does require additional text and the use of CSS to place it out of view.
The next approach uses aria-describedby on the button to point to a span containing the User name text . This would augment the Accept and Reject button with the user name. This requires no additional text, you just need to include an id on the span (or other element) containing the user name text. This was not consistently supported in the browsers and screen readers.
Adding an aria-label onto the button element with the label for the button is easy enough. It does require the extra text as the value of the aria-label attribute but is easy enough to implement. Unfortunately, there is no current browser support for aria-label but it is coming in the next release of Firefox.
And lastly, just adding a title attribute on the button with the additonal information about which invite user it is associated with. This has fairly good support but does depend upon the user screen reader settings.
I compiled the results of testing with Firefox 3.0.8, a daily Firefox/Minefield build, and IE8 with JAWS 10, Window-Eyes 6.1 and NVDA 0.6p32 so you can compare the results and draw your own conclusions.
Hopefully the ARIA examples are helpful as well – I’ll try to do more!
Yes, Chris, I probably should have just used the same text for all of the examples! I was sort of playing with different options and amount of description provided. Although, the labelledby needs to include the full text of the button and I’m not sure designers would have added “accept user name” and “delete user name” text anywhere visible within the invite.
I had originally marked the “accept” and “reject” text of the button elements with role=”presentation” because I thought that the screen readers would speak it in addition to the labelledby. But, as it turns out, the just the labelledby element is what is spoken. Thus, that element needs to contain the exact text to be spoken for each button.
I may be missing something, but couldn’t you use the best parts of the first two methods, i.e. use @aria-labelledby to point to an existing element containing the label text? It looks from the test results like one of the big issues is support for @aria-describedby vs. @aria-labelledby.
On anchors I provide the title attribute and offscreen text within anchor. I recommend this for coding tabs (eg. “tab 2 of 4, active” the word active is dropped when another tab is active).
JAWS supports label and title if different for INPUT elements (though it is currently broken and I have filed a bug with FS).
It is a problem that user agents and AT makers do not all support all standard elements and attributes uniformly. What then is the guarantee that they will support ARIA in a non-haphazard way?
Rightho,
Sailesh
Yes, I am actually surprised that the title attribute works as well as it does. I didn’t expect that when I first approached the problem. I wonder if the title attribute would work as well in other situations that are not buttons, anchor or input elements?
You are correct that the simplest HTML solution should be used, but I suspect there may be situations where ARIA could be used to provide additional augmentation not available in HTML. Can you think of any examples?
Both WinEyes 7.01 and JAWS 10 read the title on the button for (Mel O Drama) with no change to settings. I checked JFW options is set to “screen text”. I am using FF 3.0.8 and IE 8.
So as you say, the title attribute does work fine and is well supported by current browsers.
As this page is superbly coded for accessibility, JFW even reads the context i.e. the page title and nearest heading text when the focus is on a button when requested to read page title. (covered in HTML techniques for WCAG2 for link purpose).
But my question is: is ARIA even needed in situations like these? The ARIA doc recommends (section 2.4): “Use native markup when possible and use the semantic elements that are defined in the host markup language”.
Thanks very much.
Sailesh