Comments on: Augmenting Button Text with ARIA

By: Becka11y

Becka11y — Fri, 10 Apr 2009 11:51:52 +0000

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.

By: Chris

Chris — Fri, 10 Apr 2009 00:19:24 +0000

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.

By: Sailesh Panchang

Sailesh Panchang — Thu, 09 Apr 2009 21:04:05 +0000

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

By: Becka11y

Becka11y — Thu, 09 Apr 2009 19:03:32 +0000

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?

By: Sailesh Panchang

Sailesh Panchang — Thu, 09 Apr 2009 17:43:54 +0000

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