Is it possible to force a screen-reader to read the alt-attribute instead of the text inside a button?
Example html: <button alt="user menu">DrKawashima</button>
When testing this with the built-in accessibility screen-reader in MacOS, I found that it only said "DrKawashima", and the alt-attribute was never used.
Is there a way to hint to screen-readers that I would rather have it say "user menu"?
Yes, it's possible - but beware of completely overriding the visible text of a button.
tl;dr - I recommend approach 4 here.
Your question addresses screen readers, but there are other types of assistive technology to consider. In particular, sighted people using speech control (e.g. Dragon Naturally Speaking). Take care to address WCAG Success Criterion 2.5.3: Label in Name.
Assistive technology deals with the computed accessible name of an element:
Screen readers will read the computed accessible name. Remember that the basic purpose of of a screen reader is to read what's on the screen - beware of trying to present a different interface to screen reader users.
Confusion can arise when a blind screen reader user and a sighted person are both talking about the same screen. For example, a telephone tech support person might say "Click on the button which says DrKawashima". But if this is overridden, the screen reader says the button is called "User menu", and the user can't find the button they're being told to press.
Sighted people also use screen readers. For example, someone with dyslexia may like to have stuff read out to make life easier. When the computed accessible name differs from the visible text, the screen reader is effectively lying to the user about what it says on the screen.
Speech control will try to match what a user says, to the computed accessible name. If a button has visible text, it's important that this text appears inside the computed accessible name of the element. The expectation is that a speech control user can activate a button by saying the visible text. In your example, saying "Click DrKawashima" should activate the button. This won't work if the computed accessible name is "User menu".
There's a work-around for this. Dragon Naturally Speaking has a tool to highlight all buttons using numbers: say "Click button", look for the number, then say "Choose 2". However this is a multi-step process, requiring extra effort from the user.
Note that the computed accessible name and the visible text do not have to match exactly. Rather, the visible text must form part of the accessible name.
Let's look at some examples:
Your example with an alt attribute on the button simply won't work, because buttons don't have an alt attribute. This isn't valid HTML:
<button alt="user menu">DrKawashima</button>.
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima". The alt attribute had no effect.
This passes WCAG "Label in name", because the visible text and the computed accessible name are exactly the same.
However it doesn't manage to inform a screen reader user about the purpose of the button; sighted users can probably infer this from an accompanying icon or avatar image.
The aria-label attribute can be used to completely over-ride the button content: <button aria-label="user menu">DrKawashima</button>.
The visible text is "DrKawashima".
The computed accessible name is "User menu". The aria-label attribute completely overrides the button content.
This approach FAILS WCAG "Label in name", because the visible text doesn't form part of the accessible name. A speech control user can't activate the button by saying "Click DrKawashima".
The aria-label attribute can be used to completely over-ride the button content, whilst duplicating the visible text: <button aria-label="DrKawashima, User menu">DrKawashima</button>.
The visible text is "DrKawashima".
The computed accessible name is "DrKawashima, User menu". The aria-label attribute completely overrides the button content, but it duplicates the visible text.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This approach is simple, but may be fragile because you have to manage two strings.
Include some visually-hidden text, to give screen reader users some additional context. For example, using HTML5Boilerplate's .visuallyhidden class, or Bootstrap's .sr-only class:
<button>DrKawashima<span class="visuallyhidden">, User menu</span></button>
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima, User menu". This results from the button content.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This is the simplest solution, very robust.
The aria-labelledby attribute can build an accessible name, by referencing 2 element IDs:
<button aria-labelledby="user-menu-visible-label user-menu-suffix"><span id="user-menu-visible-label">DrKawashima</span><span id="user-menu-suffix" class="visuallyhidden">, User menu</span></button>
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima, User menu". This results from concatenating the two elements refernced by aria-labelledby.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This is robust, but a bit more work to implement because you need to manage the ID references.
'alt' is not an allowed attribute within a button element. The alt attribute works with area, img and input type="image". Check out more on the topic https://www.w3.org/TR/html5/dom.html#translatable-attributes and https://www.w3.org/TR/html5/dom.html#global-attributes-2
Your best bet is to use a styled <span> tag inside the <button> with aria-hidden
<button aria-label="screen reader text">
<span aria-hidden="true">Visual Text</span>
</button>
Edit: As discussed in comment this isn't the best approach.
As a speech control user can't activate this button.
andrewmacpherson's answer provides a more inclusive solution to this.
Related
There is a contact form and when submitted it is not directed to a different page, it acts on the same page and gives a flash message that the forum has been sent.
<span class="form-submitted">Thanks For Submttied</span>
The form-submitted class is unique class and only appears when the form is sent.
I need to track, when this element appears on page.
How I can track the measurement?
If I understand correctly, the element is displayed once the form is submitted. For that, GTM has a "Visibility trigger", that can trigger tags when the display property of the element is changed, or when it is dynamically inserted into the page.
Go to "Triggers", create a new trigger, select "Element Visibility" as trigger type, change "Element Selector" from "id" to "CSS Selector" and enter the class of your element.
If your element is inserted dynamically rather than made visible via CSS styles, you need to check the "Observe DOM changes" checkbox. Checking for DOM changes is an expensive operation, so you will get a warning that this might affect performance (although in my experience this is more of a theoretical concern).
Caveat is that the element needs to be visible to the user, i.e. inside the viewport. If it appears outside the viewport (e.g. in a small browser window) the trigger will not fire.
Just as the title says.
I cant find ANYTHING for this particular usecase Online.
This is in context of a website aiming to be AA WCAG 2.0 conform.
I have non-focussable text alongside focussable textinputs inside of a single view.
I can TAB through the focussable textinputs, but I cant read out the textfields inbetween. When I press "arrow down" while having the focus on the textinput I get "empty field" from NVDA. Most shortcuts also unfortunately produce text in the textinputfield instead of executing the associated behavior in NVDA.
Is there any way have the keystrokes being recognized as commands instead of input for the textfield? Is there any keyboard shortcut telling NVDA to behave like this?
Under the hood, NVDA auto switches to Forms mode, so what you're getting is the correct behaviour. if that text is related to the field, then you should use aria-describedby="[id of text]", on the form element.
I wouldn't be looking at anything that changes the default behaviour of how it works, as this will undoubtedly cause issues, for end users.
Could you not put that text in a tooltip, that is only shown when a user tabs to an interactive icon, next to the input (using the aria-describedby attribute too)?
I'm developing a page that is structured in this way:
On the bottom I have three buttons. When I click a button, I show an image on the left and a short description on the right.
Now, I need the voice synthesis (like NVDA and JAWS) to note the appearance of the text.
Is there a standard for this behavior?
Yes, you can use WAI-ARIA for this, there is an attribute called aria-live that you would put on the container that the text appears within, with a value of "polite" to indicate that the screen reader user should be informed, but it shouldn't interrupt mid-sentence.
For example:
<div aria-live="polite">Text appears here</div>
You shouldn't need to do anything else but update the text for it to be announced by the screen reader, you don't need to change the attribute with JavaScript or anything like that. The attribute tells the screen reader that it should announce whenever a change is detected.
If you find that it's announcing more than you want, or not enough, you have a little but more granular control with the aria-relevant attribute, which can contain a space-delimited list of one or more of the following values:
"additions" Insertion of nodes into the live region should be considered relevant.
"removals" Deletion of nodes should be considered relevant.
"text" Changes to the textual content of existing nodes should be considered relevant.
"all" Equivalent to additions removals text.
aria-relevant="additions text" is the default value on a live
region.
Above quoted info taken from https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-relevant_attribute
The aria-live attribute seems to be a good option.
Possible duplicate of question answered here:
Getting screen reader to read new content added with JavaScript
I want to reveal some hidden text/elements(whatever) when some checkboxes/radio buttons are selected(assume there is a list of checkboxes/radio buttons to choose from).
What should I do to meet the WCAG 2.0 AA standards?
And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons.
Thanks!
Your last statement gives me pause: "And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons."
If you have non-standard behavior for your radios/checkboxes, will the sighted user be confused too?
With 'normal' behaving radios/checkboxes, the AT user will understand them just like a sighted person does - experience. You learn that a radio is a group of mutually exclusive choices whereas a list of checkboxes allows multiple choices. The screen reader will read the role of the object so the AT user will know what to do.
Now, if you're hiding/unhiding objects based on those selections, the AT user needs to be notified. That's typically done with aria-live. By default, an aria-live region will be read if the text changes or an object is added to the DOM which should include being unhidden if you're doing it via display:none. If you unhide by moving an offscreen object to onscreen, or changing the clipping rectangle, or changing the size of the object, aria-live will not help.
Also look at aria-relevant. By default, it's value is 'additions text', which is the behavior I mentioned above. If you need the aria-live region to be read on other conditions, look at the other values of aria-relevant.
In my case, add something like className: "btn btn-default" to a react-router Link.
Like so: <Link className="btn btn-default" to={linkUrl}>Go!</Link>
Would tha tripped people who use assistive technologies to view a site?
Some general tips on when to use an <a href> versus a <button> or <input type="submit">:
If the user is going to a new page (or anchor on the page), use a <a href> (spec).
If the user is changing a state on the current page, use <button> (spec).
If the user is submitting a form, use <input type="submit"> or <button type="submit"> (spec).
I caution against changing the default role of an element with the role attribute, as that can ultimately cause some confusion and potentially conflict for some assistive technology. These also violate the first and second rules of ARIA use.
Consider the keyboard experience as well. A hyperlink (<a href>) can be fired by pressing the enter key. But a true <button> can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. Users of some assistive technology will expect behavior based on the element used.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
So start with the right element for the task using the list above, then style it to look however you want.
tl;dr best practice is to make things look like they act but you may not have the luxury, so now what role should the element have?
You should style and role your links and buttons so they communicate this to the user. This is general good usability practice.
However, that only works in a world in which branding and marketing people don't have any say. Have you ever heard the argument "we need to make that link more prominent so visitors click on it more..." This is where links start turning into these monsters that are no longer identifiable by how they look AND act.
So now you have stumbled on one of the great debates of accessibility: should something have the role that matches how it behaves or should it have the role that matches how it looks?
A link is an element that directs the browser to another location (either another page, or another location on the same page). This is how it was designed.
Buttons on the other hand are designed to interact with the page or submit data.
The complication is, when you have a link that looks like a button and a blind user phones support and the support person says "click the X button" and the screen reader announces Y link (because the text alternative for the button is wrong), then the blind user gets really frustrated because they can neither find a button nor something that matches the X.
However, if you are trying to do accessibility the right way and your link text matches the visible information for the element, then IMO you should always have a role on the element that matches the way it behaves.
In your specific example, someone using a speech recognition system like Dragon would have difficulty clicking the link because they might use a command like "buttons" to list all the buttons and not see the element they are expecting. This user would then have to guess that it is in fact a link, or use mouse targeting to interact with the element.
The points raised by aadrian and unobf above are accurate and well stated. There is still another reality which cannot be avoided that forces the developer's hand.
Designers frequently deemphasize one or more actionable element in a group, a delete button for example, because it is used less frequently or catastrophic if used in error. Research suggests catastrophic errors can be reduced using this strategy.
Since many seasoned professionals demand that the markup for the control matches the presentation, the developer's first instinct may be to mark up the delete control as a link.
Assistive technologies for the visually impaired such as Jaws rely on lists of controls of a single type. Surveys indicate this strategy is utilized by the visually impaired fairly frequently.
With these accessibility realities in mind, it is a very bad practice to mark up a list of actions as some buttons with one or more links for actions such as delete. The visually impaired user will likely not associate the link with the buttons and may miss the link entirely.
This reality essentially forces the developers hand. If the design calls for a delete link in a list of buttons, the developer must mark up the link as a button, even though the keyboard navigation will not align perfectly for the sighted user.