Which is the correct way to make inline tooltips accessible?
I have 2 versions below.
Version 1: Use the title attribute. When hovering I will use JS to hide the title attribute and add the text to my custom tooltip. I will add back the title attribute when hover is off.
<p>For here am I sitting in a <span title="A spaceship">tin can</span> far above the world planet earth...</p>
Version 2: use aria=label and role="tootlip"
<p>For here am I sitting in a <span aria-label="A spaceship" role="tooltip">tin can</span> far above the world planet earth...</p>
Note: this question is for inline tooltips only, meaning the tooltip text is in the attribute of the element which triggers the tooltip. The tooltip is not separate from the element triggering it.
The title attribute by itself does not reliably provide an accessible name for the element, meaning it will not be read by all screen readers.
Aria-label has no function if it is not assigned to an interactive element. Beware also, that the aria-label replaces the element’s content from an accessibility perspective.
Since you want to use that attribute only to inject another element with that text as its content, the issue here is more one of confusion, and it might be better to use a non-semantic attribute in that case like data-tooltip.
The aria-label attribute defines a string value that labels an interactive element.
Which brings us to another aspect: The tooltip needs to work with touch screens and keyboard, too. So it will need to be focusable and focus needs to be visible. A tooltip should also be closable by means of Esc.
A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. It typically appears after a small delay and disappears when Escape is pressed or on mouse out.
https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/
Since aria-describedby is recommended for screen readers to reference the additional contents, it is better to have that element already in the DOM, which would simply be hidden or shown depending on tooltip state.
<p>For here am I sitting in a <span aria-describedby="tooltip-spaceship" tabindex="0" role="tooltip">tin can</span> far above the world planet earth...
<span id="tooltip-spaceship" hidden>A spaceship</span></p>
Lastly, the least expensive way, which is easier to use as well, is to simply provide them in the text at their first occurrence:
<p>For here am I sitting in a <dfn>tin can</dfn> (a spaceship) far above the world planet earth…</p>
See also Understanding Success Criterion 3.1.3: Unusual Words
Related
(This question is similar to Should ARIA labels provide context?, but not identical, as I'm talking about buttons and do not have full control over the markup.)
I have some amount of items and buttons that act on those items. Here's a simplified example:
<ul>
<li><span>Item: foo</span> <button>remove</button></li>
<li><span>Item: bar</span> <button>remove</button></li>
<li><span>Item: baz</span> <button>remove</button></li>
</ul>
As far as I understand, when someone using a screen reader tabs through the page, they will be read the button text but not the item text. This doesn't seem ideal to me, as they don't have context on which item the button will remove.
Assume that I don't have full control of the markup; I can only add attributes.
What is the best practice in this situation?
add an aria-label to the button that gives more context:
<button aria-label="Remove item foo">remove</button>
make the item text itself tabbable and give it an aria-label so it's read aloud:
<span tabindex="0" aria-label="Item foo">Item: foo</span>
leave things as they are, because this is intended behavior and/or I'm misunderstanding something about screen readers
something else entirely?
The answer depends on if you're trying to conform to the Web Content Accessibility Guidelines and are only worried about compliance issues (from a legal perspective), or if you want to have a great user experience regardless of whether you conform or not.
The first part, conformance, is a little tricky. Regarding context, 2.4.4 Link Purpose (In Context) comes into play but only for links. The guideline says the text for a link is ok if the user can figure out the meaning of the link from the link text and the surrounding context (such as what text is before or after it). And then context is defined as the link being in the same list item (<li>) as the surrounding text.
So that sort of fits your scenario, but you have buttons instead of links, so WCAG 2.4.4 doesn't really apply to you.
There isn't a clear guideline for the context of buttons except WCAG 2.4.6 Headings and Labels. It says that the label [of a button] must describe the purpose of the button. So who decides whether the label is descriptive enough? That's a tough call. Is "remove" descriptive enough? Maybe, maybe not. It kind of depends who you ask.
So if you are focusing on a great user experience rather than conformance to WCAG, adding context to the buttons is a really good thing.
You are correct that if a screen reader user tabs through the interface, they will only hear the button label and not the list context. But screen reader users have many ways to navigate a webpage. One option is to navigate by list elements (<ul> or <ol>) by using the L key (JAWS and NVDA). Another is to navigate by list item (<li>) by using the I key. (That's the letter 'i', not a number 1). So a user can navigate to your list items, hear the text of the list and the text of the button and get some context.
I would not recommend your second idea of adding tabindex to the list. You don't want the user to tab to elements that are not interactive.
Adding more context via a label is the best approach. I would recommend using aria-labelledby before resorting to aria-label. If you have an element in the DOM already that has the text context you need, give that element an ID and then refer to that ID in the aria-labelledby of the button. It's a little more work but then you don't have to worry if you change the text in the list because the button is using an indirect reference and will automatically pick up the new text.
You'll also need an ID on the button and then you have the button point to itself and to the context. That sounds confusing but here's all it is:
<ul>
<li>
<span id='item1'>Item: foo</span>
<button id="button1" aria-labelledby="button1 item1">remove</button>
</li>
<li>
<span id='item2'>Item: bar</span>
<button id="button2" aria-labelledby="button2 item2">remove</button>
</li>
</ul>
A simpler approach is to use aria-label as in your first suggestion but I don't like repeating text in an aria-label that's already in the DOM. If your list text changes at some point, you have to remember to change the aria-label too.
Making the span focusable is a very bad idea unless it produces an action itself when clicked. Only elements that are actually interactive should be focusable.
It's very confusing for the user is something is focusable but don't provide any interaction when focused.
Adding context with aria-label is a good idea, but in fact there is better.
The recommended way is to add off-screen text instead:
<button>Remove <span class="sr_only">Item 123</span></button>
Where .sr_only is a CSS class present in many frameworks with different names (sr_only, visually-hidden, etc.) which send the text off-screen. It is invisible for normal users, but read as normal by screen readers.
I am trying to optimize a few components for screen readers, however Android Talkback proves to be a challenge....
Here is a very simplified example for the code:
<div class="wrapper">
<form>
<span role="presentation" aria-hidden="true">
This should not be read by Talkback
</span>
<input aria-label="This should be read by Talkback" />
</form>
</div>
The text inside the span is updated dynamically, and is positioned absolutely over the input - just to appear like an animated placeholder, without actually being read by screen readers. That is what the aria-label is for. However, TalkBack still seems to recognize the span - so it reads the content of the aria-label first, then continues reading the text in the span... role "presentation" or role "none" did not prevent this, neither did moving the text even further from the input. (For example, outside the form). Is there any way to prevent this?
The role attribute only changes the type of element that Talkback and other screen readers announce. Setting it to presentation or none just removes the semantic type of element. A <span> does not have a native role by default so it's essentially presentation/none implicitly and won't have any effect.
aria-hidden is the key. It will hide the element from the screen reader. (CSS display:none and visibility:hidden will also hide an element from the screen reader but it also makes the element invisible to sighted users too.)
Your code example should work just fine with Talkback. However, you mentioned that you dynamically change the contents of the <span>. That's not a problem but is there a chance that when you updated the text, the aria-hidden got removed?
I have used aria-hidden on Android without any trouble.
The solution in my example was already enough to fix the issue.
aria-hidden prevents the span being focusable, and if the span is located before (and not after), TalkBack will not interpret the text as being part of the input.
I am building an app which has to be WCAG compliant. It requires about 12 buttons. Some of the buttons have only tooltips and icons but no labels. I haven't been able to find clear cut language in WCAG about this problem. Are titles necessary for buttons?
Short answer
Yes, your button must have so form of text label associated with it.
But don't be confused with <label>, which is normally unneeded for a button.
Long answer
The answer isn't answered directly in WCAG, but this is a question of perception, which is the first WCAG core principle.
If your button has only an icon but no alternative text or label, it follows that screen reader users won't perceive your button.
So, in the broad sense, yes, your button must have a kind of label.
You have several ways to set an accessible label, technically known as accessible name, to a button having no text itself:
Attribute alt of <input type="image"/> or the <img/> which is inside the button
aria-label or aria-labelledby attributes
Visually hidden text
Don't be confused with <label> element. It's unneeded for a button, since a button usually carry its own accessible name.
An <input type="text"/> need a separate <label> because it has typically no accessible name otherwise.
This may also be a question of understandability, which is the second WCAG principle.
Even for perfectly sighted people, are you sure that the meaning of your button without any text is crystal clear ? Few icons are known to be almost universally understood by everybody without any hint, any help, any tooltip, nothing.
IN that quite small list you can certainly find multimedia buttons (play/pause/stop/record), parameters/settings wheel, power on/off, but probably not many more.
As a consequence, the question isn't only about having an accessible name for screen readers. It goes much beyond that.
To wrap up, yes, your button definitely must have some form of text label associated with it.
Short Answer
You should add aria-label to your buttons.
Longer Answer
Buttons need a name that can be computed for accessibility. First to answer your questions:
Are titles necessary for buttons?
No
Should buttons have labels from WCAG point of view?
No once again, in fact they are probably not valid.
So what should I do?
Buttons don't need titles or <label>s (in fact a <label> on a button would probably not be valid without some WAI-ARIA).
But, they do need to have an accessible name, and I think this is the part that is causing confusion.
Because your buttons only have an icon and a tooltip, they probably / possibly do not have any text that is useful to assistive technology (such as a screen reader).
So when they reach a button with just an icon using a screen reader they will hear "button", with no indication of what the button is for!
The fix
There are several ways to approach this, but the easiest is aria-label.
WAI-ARIA is a set of attributes you can add to HTML elements to add extra meaning / semantics to make a page make more sense to assistive tech users.
The aria-label attribute, when used on an interactive element (such as a button, an anchor / hyperlink etc.), will indicate the the browser "hey, please present this as the accessible name for this element.".
So in your example, something similar to the following would ensure that the purpose of a button is clearly described:
<button aria-label="Add New Document">
<!-- your icon -->
</button>
So instead of just saying "button" when focused it will now say "Add New Document, button".
In an earlier version of the http://getbootstrap.com/components/#pagination page/section, it had the code:
<nav>
<ul class="pager">
<li class="previous"><span role="presentation">←</span> Older</li>
...
</ul>
</nav>
This has been changed to:
<nav>
<ul class="pager">
<li class="previous"><span aria-hidden="true">←</span> Older</li>
...
</ul>
</nav>
The left arrow (←) is purely decorative, and doesn't need to be announced by a screen reader. According to http://www.w3.org/TR/wai-aria/roles#presentation:
presentation (role)
Example use cases:
An element whose content is completely presentational (like a spacer image, decorative graphic, or clearing element);
An image that is in a container with the img role and where the full text alternative is available and is marked up with aria-labelledby and (if needed) aria-describedby;
...
Whereas:
aria-hidden (state)
Indicates that the element and all of its descendants are not visible
or perceivable to any user as implemented by the author.
I understand that 'role=presentation' is really talking about the semantic meaning of the element, but it seems like the left arrow is directly analogous to 'a spacer image, decorative graphic, or clearing element', and is certainly 'visible or perceivable to any user'.
What's the correct design pattern here? Is the meaning of 'aria-hidden' changing to allow for this specific limitation of 'role=presentation'?
The role attribute is used to override the default mapping of the role of the HTML element to the accessibility tree. This has no effect on the text content of the element.
For example, role="button" on a div will allow the div to be announced as a button but will not change the fact that the text of the div (e.g. "Submit") will still be announced as the accessible name.
In ARIA 1.1 the presentation role has been given a synonym of "none" to better represent its semantic http://www.w3.org/TR/wai-aria-1.1/#none
The attribute aria-hidden is used to hide the element itself and the content (accessible name) of the element from the accessibility tree while keeping it visible in the document. This semantic has always been the case. It has not changed.
unobf is correct but sometimes it helps if you think of what the screen reader user will experience. Consider this simple example:
<div role='button' tabindex=0>alpha</div>
<br>
<div role='presentation' tabindex=0>beta</div>
<br>
<div role='button' tabindex=0>gamma</div>
<br>
<div role='button' tabindex=0 aria-hidden='true'>delta</div>
<br>
<div role='button' tabindex=0>epsilon</div>
If you're using VoiceOver or the virtual PC cursor in JAWS, both will allow you to put your focus on the role='presentation' item and will not state a role but it will say 'beta'. (I like the new role='none' that unobf points out in the 1.1 spec. It makes it clearer that the screen reader should not state any role when it's set to 'none'. As the spec says, it was a little confusing using 'presentation'.) So the presentation item isn't really hidden to the screen reader. You're just telling the screen reader that it doesn't have a role.
Aria-hidden, on the other hand, completely removes it from the screen reader, except in my poor example (which is intentional). If you're using VoiceOver or the virtual PC cursor in JAWS, both will skip the aria-hidden button. The screen reader user won't know it's there. But if the JAWS user is TABBING through the page, they will land on the aria-hidden button because it's a tab stop. But since it's aria-hidden, JAWS gets a little confused on what to say. When I tried it (FF 38 and JAWS 16), it said 'beta', which is the text from a previous <div>. In general, you don't want to aria hide something but make it keyboard accessible. That's just a weird scenario.
Going back to bootstrap's old example, since they used role='presentation' and it's a <span> tag, the VoiceOver and virtual PC cursor JAWS user will both be able to put their focus on the <span> element, which is probably not what they intended. Since the arrow is just for decoration, it makes sense to aria hide it.
Is there any alternative to <div>? My website is losing "accessibility" because I cannot set focus on a <div>. What control should I use in order to replicate <div> and still hold focus?
This is what my HTML looks like:
<div style="height:70px; overflow:hidden" id="divMsg">
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
</div>
You can add tabindex to make it focusable; however, this is usually not enough. If you want the element to be clickable, you will also need to add a keydown or keypress handler so that the user can activate it using ENTER, similar to a A link. Otherwise the user will be able to tab to it, but may not be able to do anything with the link after.
If you are trying to create a clickable element, it is sometimes simpler to start with a A tag, and then style it so that doesn't look like a link. A elements respond to both keyboard and mouse and fire onclick for both, so you don't have to do additional keyboard input handing like you do with a DIV.
Finally, if you are making a DIV or A that visually looks like a button or some other control, add the appropriate ARIA role so that a screenreader will call out the appropriate element type - eg.
Complete Transaction
Just give it a tabindex attribute.
If you are specifically looking for accessibility, try out the new HTML 5 tags like <article>. So for example a textreader knows what to read, and your page is much better structured.
Check out this site.
To answer your exact question, it depends why you are using the div; I'm guessing for layout. The tab ordering is dependent upon more than tabindex, as defaults and overflow affects positioning and focus.
To be more specific, you won't use a div to latch onto for tabindex. Rely upon JavaScript and a unique ID; <div class="content" id="page1">
This will also provide you an anchor so you could use http://index.html#divMsg to link focus to the exact place in your HTML document. Note you have only one div ID and reuse the same div class twice in your example.
If this is all new to you the article on difference between ID and CLASS may be of interest to you
Links (element a) and form elements (input text and alike, file, radio and checkbox, submit, image and type button, select, textarea, button element, etc) are focusable by default.
Thumb rule: if an element does something, it should be a link or a form element part of a form. (OT: I guess I've a problem with conjugation here but can't find exactly what - english isn't my mothertongue)
Think twice (at least :)) before using the tabindex attribute: it'll work for a while in your project and then you make some modification elsewhere and suddenly all is broken. And it'll break again, again and again.
For testing with Safari, you'll need to modify Preferences: this browser (maybe also Chrome?) only cycle by default through form elements and not links. Users of keyboard cycle through every focusable elements I guess, like in IE and Firefox.
To learn further, Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have Sufficient Techniques (and "Failure(s)" also) about keyboard use.