WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Button and textual equivalent

for

From: Jukka K. Korpela
Date: Dec 5, 2014 2:43PM

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, that’s 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 there’s 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