WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Button and textual equivalent

for

From: Birkir R. Gunnarsson
Date: Dec 5, 2014 2:31PM

Lucia

Assuming the font image is accessible and visible to all users, I do
not see a problem here.
aria-label is a perfectly valid labeling mechanism, and comes before
the title attribute in the accessible name calculation algorithm:
http://www.w3.org/TR/wai-aria/roles#namecalculation

The title attribute might possible be more compatible with older
assistive technologies (I think pre Jaws 9, pre Window Eyes 8 and pre
NVDA cirka 2011.1) , but suffers from the same deficiencies as
aria-label in that it is not accessible to sighted keyboard only
users.
But sighted keyboard only users see the image, we assume users of
screen magnification can see the image (color contrast and all that is
met), and screen reader users are fully covered by user of aria-label.
I am not sure on speech recognition and title vs. aria-label though,
so that is my one area of concern, but in terms of WCAG compliance, I
could not call this a violation.


On 12/5/14, Lucy Greco < <EMAIL REMOVED> > wrote:
> Hello,
>
> I was hoping some one could help me answer this query. Below is some code
> from a developer and a description of what they are doing and how we think
> it might be fixed. My concerns are that the dev team working on this has
> very limited access to the code and may not be able to do any of the things
> we are recommending. I have tested with NVDA and JAWS and both have no
> problem with this button so how should we proceed with our recommendations?
>
> Note also the message from our testing tool is included.
>
> Note from testing tool and code:
>
> Button is missing a textual equivalent (on-screen text, title, or
> image with alt attribute.
>
> <button type="submit" class="btn btn-default" aria-label="search
> button" value="Search"><span class="entypo search"></span></button>
>
> Technically, I'm not sure if this is a violation or not. If it's a
> violation, it's because the aria-label and value attributes don't count as
> textual equivalents. I can see how that would be true - aria-label adds the
> text to the accessibility tree, but it's not available if you're not
> looking at the accessibility tree. The value attribute used to be what was
> displayed as the text of the button (when it's coded as input type=submit),
> but the new HTML5 button tag may work differently. Obviously they're not
> displaying any text on this button, they're using a font icon.
>
> If it is a violation, the solution could be either to add a title attribute
> to the button, or to include some text within the button tag and put it
> offscreen. As long as the keyboard focus works on the button itself, they
> shouldn't need to show the text on focus. My recommendation would be to add
> a title attribute. We should also test whether that means they can leave
> off the aria-label.
>
> Any thoughts would be appreciated!
>
> --
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
> > > >


--
Work hard. Have fun. Make history.