E-mail List Archives
Thread: Button and textual equivalent
Number of posts in this thread: 5 (In chronological order)
From: Lucy Greco
Date: Fri, Dec 05 2014 2:21PM
Subject: Button and textual equivalent
No previous message | Next message →
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
From: Birkir R. Gunnarsson
Date: Fri, Dec 05 2014 2:31PM
Subject: Re: Button and textual equivalent
← Previous message | Next message →
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 ADDRESS 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.
From: Jukka K. Korpela
Date: Fri, Dec 05 2014 2:43PM
Subject: Re: Button and textual equivalent
← Previous message | Next message →
2014-12-05, 23:21, Lucy Greco wrote:
> I have tested with NVDA and JAWS and both have no
> problem with this button
Exactly how do they inform the user about this? There must be something
odd going on if this button works.
> 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>
I think the element falls into the category "non-text content", since
there are no characters in its content. I guess Guideline 1.1.1 could be
interpreted so that it suffices to add a name=... attribute to the
<button> element. This would affect the functionality, since then a
name=value pair would be included into the form data, though this would
probably be harmless.
Obviously, there is some CSS that causes some image to appear in the
button. The page thus fails the simple test "does it work at all without
CSS?", though such a test is not, unfortunately, included in WCAG 2.0
(unless I am missing something). More importantly, there is no way to
specify textual alternatives for images implemented as background images.
> 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.
The <button> element was already in HTML 4, and by definition it is the
content of the element that is rendered in the button. The value=...
attribute has no role here. It affects only the submitted data, and even
that even if a name=... attribute is also present. Possibly the person
who wrote the code was mistaken about this.
> Obviously they're not
> displaying any text on this button, they're using a font icon.
Well, thats another possibility. They are then using CSS generated
content to add some character and set the font to a special font. The
character is typically some Private Use code point, which has by
definition no meaning outside of private agreements, and speech
synthesis must ignore it or just tell that theres something uncipherable.
Well, they *could* also add a word like "Search" via generated content.
Then things would be accessible, provided that CSS is enabled. It would
be odd to do so, instead of simply having the text in the button. Some
some strange method of localization via CSS?
Anyway, we need the relevant CSS and JavaScript in order to analyze the
situation.
> If it is a violation, the solution could be either to add a title attribute
> to the button,
A title attribute is advisory/auxiliary and should never be relied on.
> or to include some text within the button tag and put it
> offscreen.
I think the question is why they don't have normal text there, or an
<img> element with alt text.
> As long as the keyboard focus works on the button itself, they
> shouldn't need to show the text on focus.
So what happens now when the button is focused on?
Yucca
From: Patrick H. Lauke
Date: Sat, Dec 06 2014 8:52AM
Subject: Re: Button and textual equivalent
← Previous message | Next message →
On 05/12/2014 21:43, Jukka K. Korpela wrote:
> 2014-12-05, 23:21, Lucy Greco wrote:
>
>> I have tested with NVDA and JAWS and both have no
>> problem with this button
>
> Exactly how do they inform the user about this? There must be something
> odd going on if this button works.
From quick test with JAWS/IE "search button...button..." and in JAWS/FF
"search button, button, to activate press SPACE bar"
NVDA, strangely, did not announce anything for me in Firefox, and in IE
"button, search". Note that it seems IE does not correctly use/expose
aria-label as the accName (tested using aViewer [1]), so this last
result is likely due to NVDA doing some kind of remediation work and
announcing the role and value of the control. Firefox, however, does
correctly expose "search button" as accName, so the behavior of NVDA
here may just be a plain old bug in NVDA.
>> <button type="submit" class="btn btn-default" aria-label="search
>> button" value="Search"><span class="entypo search"></span></button>
>
> I think the element falls into the category "non-text content", since
> there are no characters in its content. I guess Guideline 1.1.1 could be
> interpreted so that it suffices to add a name=... attribute to the
> <button> element.
Name? I don't recall the name attribute being exposed at all in anything
other than form submission data - and pretty sure it doesn't act as a
fallback text content.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Sat, Dec 06 2014 9:06AM
Subject: Re: Button and textual equivalent
← Previous message | No next message
On 06/12/2014 15:52, Patrick H. Lauke wrote:
> NVDA, strangely, did not announce anything for me in Firefox, and in IE
> "button, search". Note that it seems IE does not correctly use/expose
> aria-label as the accName (tested using aViewer [1]), so this last
> result is likely due to NVDA doing some kind of remediation work and
> announcing the role and value of the control.
Ah, it seems the problem was when copy/pasting Lucy's code, I overlooked
the line break between
aria-label="search
button"
Removing this line break made NVDA/IE correctly announce "button, search
button" and IE expose "search button" as the accName.
(also, forgot to add the link to aViewer in my previous email:
http://www.paciellogroup.com/resources/aviewer/)
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke