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!


About Becka11y

Web Accessibility Consultant with 30+ years in the software industry and 12+ years of direct accessibility innovation.

6 comments:

  1. Hi Steve,Thanks very much for looking into this in more deaitl and sorting out what’s really going on. While I guess the conclusion that aria-labelledby should be spelled properly still holds, it’s good to know that Internet Explorer’s behaviour is not because it supports the incorrect spelling aria-labeledby , but because, in the absence of a correctly spelled aria-labelledby attribute, it makes its own calculation of the alertdialog s accessible name based on the dialog’s text content.I appreciate the fact that in your tests you have the referenced label outside the actual alertdialog, which certainly helps to distinguish between label and dialog text content, and more clearly indicate what the browser is using to construct the accessible name.Things may have worked better for me had I used Accessibility Probe (AccProbe), which clearly indicates that IE is constructing the accessible name using all of the text within the dialog. I had relied on Accessibility Viewer (AViewer), which does not seem to work the same. For instance, using AViewer with my second alertdialog example, where the attribute is spelled incorrectly, the MSAA accessible name from IE is indicated to be alertdialog #2 label . This, I suppose, is why I mistakenly assumed IE was actually supporting the incorrectly spelled attribute. On the other hand, using AccProbe, the accessible name for the same example in IE is indicated as alertdialog #2 labelText for alertdialog #2Close . This is consistent with the situation as you revealed it to be. So, hey, I learned a few things today, which is always nice Thanks for that.One last question about your test results: I read the results table as saying that, with aria-labelledby correctly spelled correctly, IE does not use the referenced label text, but just the dialog’s element text, i.e., this is dialog text . As far as I can tell using AccProbe, IE8 and IE9 use the referenced element text content correctly labelled for the component’s accessible name. Am I reading this right?

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

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

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

  5. 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?

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

Leave a Reply

Your email address will not be published. Required fields are marked *