I have a requirement to make a button that has a tooltip which provides some simple statistical information to a user. (a student's grades for example: "Homework: 100%, Exams: 85%") When the user clicks that same button it should bring up a modal with more detailed information. (Like each assignment's grade for example). I need this to be accessible for screen readers. I am using Bootstrap 5 as a framework. I've seen suggestions that are not ADA compliant for accomplishing this task. What is the best way to do this and have it be accessible?
If the tooltip is only available to mouse users, then that would be an accessibility issue. A keyboard user should be able to tab to the button and see the tooltip.
Say what you will about IE but it had a nice built in feature that tooltips (title= attribute) were displayed by the browser when the user navigated to the element with the keyboard. Fortunately, Edge also does this. Chrome and Firefox do not so you'd have to code this yourself.
Secondly, the tooltip text needs to be programmatically associated with your button so that screen readers can announce the tooltip text. You should get this behavior for "free" because of the "Accessible Name and Description Computation".
The "accessible name" of the button should come from the button text (step F in the previous link, "name from content"). Eg <button tooltip="grades">open dialog</button> will have an accessible name of "open dialog".
The "accessible description" of the button should come from the tooltip (step I ["eye"] in the previous link) if the description can't be found in other attributes (such as aria-describedby). Eg <button tooltip="grades">open dialog</button> will have an accessible description of "grades".
When a screen reader user navigates to the button, they will typically hear the accessible name followed by the accessible description (among other info such as the type/role of the element and possibly the state [such as aria-pressed]). So you shouldn't have to do anything to get the tooltip read but you'll want to test it in several browsers (Chrome, Firefox, Safari) with various screen readers (JAWS, NVDA, Voiceover).
Note that the screen reader user can turn off descriptions so that they'd only hear the accessible name and not hear the tooltip, but that's totally up to the user. As long as you coded it correctly, you don't have to worry about that scenario.
There's no real way to make a tooltip on a button that's accessible, since touchscreen users have no way to trigger it without triggering the button. Tooltips are also confusing, since even mouse users who can trigger a tooltip may not realize there is anything there to trigger.
The best approach in your case is likely to include the information from the tooltip in the modal itself as plain text. (You can keep the tooltip or remove it.)
This will improve the experience for other users too. This "simple statistical information" seems like it would be handy, and having it as part of the modal allows it to be copied (for example), unlike a traditional tooltip.
For constructing the modal itself, I would follow Bootstrap's example code.
Related
In Material UI Autocomplete Free Solo, I noticed that the "Clear input" button is clickable, but not accessible by keyboard.
I went into the codebase to understand the reasoning behind this decision but didn't find anything. I also checked the A11Y docs but without success either... Could anyone give a little more detail about this? Was it a decision based on user testing?
Code that adds the tabindex="-1"
Testing the tabindex="-1"
Thanks :)
As far as why it's behaving the way it is, you already discovered that. tabindex="-1" means the element should be removed from the normal tabbing order but still allows the elmenet to be focused programmatically (if you call obj.focus() from javascript).
If you're asking why Material decided to not have that button focusable, #rafael is correct that that's not a stackoverflow question. Someone working for Material that happens to be on stackoverflow might see this question and try to answer it but you're more likely to get an answer if you ask them directly.
Note that WCAG 2.1.1 is often misunderstood that every interactive element on the page must be accessible via the keyboard. That's not true. What that checkpoint says is that all "functionality" of the page must be accessible through the keyboard. In the case of the X-clear button, that functionality is also available via the keyboard because when you TAB to the input field, all the text gets selected so you can either press DELETE or BACKSPACE to erase it or just start typing new text. Or you can press Ctrl (or CMD) + A to select all the text and delete it.
So all the functionality of the X-clear button is available to the keyboard user without the actual button being accessible.
Now having said that, I rarely, if ever, make a button that is clickable with the mouse not available to the keyboard user.
I am improving the accessibility of a website to make sure users can easily navigate using the keyboard only. There is a button that generates a file, but after clicking on the button, the generic browser download dialog appears at the bottom of the page, and the focus still stays on the button. Users with a screen reader are not notified about the dialog.
There is a way to focus on the dialog when it appears?
I am able to focus on elements of the page, but since the dialog is a browser feature, I have no idea how to do it!?
I will appreciate any guidance what can you give me. Thank you!
You do not have control to do this, plus this is expected behaviour and there is nothing you need to do.
Screen reader users will go out of the active screen using shortcut keys if they wish to access the file.
Other considerations as you said "button" in your question
You should not use a <button> element to generate a file. File downloads should always be a hyperlink (<a>).
If the document requires variables to be passed and you are able to pass them via a GET request then the hyperlink href should be the URL + GET parameters.
The advantage of this for everyone is that they can middle click to open the document in a new window (or right click and choose "open in new window" etc.), plus it works without JavaScript and is easily indexed by Search Engines.
Also adding the download attribute to a hyperlink has some advantages, especially as in some screen readers it gets signalled to users that this link will download a document.
When creating a download link you should state the document type (pdf, word etc.) and document size for accessibility. You can do this with visually hidden text if your design does not allow for it.
I have written a reasonably in-depth answer on how to add the file size and file type info for screen readers here. About 70% of it is relevant to you.
I'm working on a client project which acts as a resource and support system for vulnerable people. Accessibility compliance has been touted as the absolute highest priority for this site because of the expected users, so we're currently working to meet WCAG 2.0 Level AA as closely as possible.
Currently the code for the login/registration links in the header looks like this:
<div class="profile-summary">
<a class="profile-summary__link" href="/login">Login</a>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
Another developer who is working on the user management system wants to change the login link to be a form containing a submit button. Something (hypothetically) like this:
<div class="profile-summary">
<form action="/login" method="get">
<button type="submit">Login</button>
</form>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
This doesn't really sit well with me and it seems like something screenreaders and other assistive software will trip over (e.g. won't read the login option when summarising the page). To my knowledge some of these switch into a 'form mode' when they encounter a form, which would be jarring in this situation.
Are there any detrimental accessibility implications to using a form and button over a plain link in this context?
Thanks!
In this context, the link with href="#" is right out.
Adding a form can be more confusing than anything because it implies a different thing will happen between each of two otherwise similar controls. A form with no fields and only a button is even more confusing to many SR users. That may be a bigger problem than the links.
Remember that not all screen reader users are blind, so if these controls look the same but behave differently that is also an issue.
Without seeing what these two controls do, it is hard to offer specific advice about which element is the right choice.
Here is generally the way I approach this question...
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an <input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This had better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead. I tend to prefer <input type="submit"> as I find it runs into fewer conflicts (both mentally and stylistically) with developers.
Keyboard User Consideration
Think of keyboard users for a moment. A hyperlink 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. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I have a CodePen demo that shows this in action: http://s.codepen.io/aardrian/debug/PZQJyd
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).
For reference: http://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html
This question already has an answer here:
Why are buttons discouraged from navigation?
(1 answer)
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
From my understanding, buttons are used to carry out functions and links are used to navigate the user to a different page. But what is best practice in terms of opening and closing a modal?
<a id="testModal" href="#">Open Modal</a>
or
<button id="testModal">Open Modal</button>
<button>
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink 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. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
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).
I think there are two possible cases.
Your content is only visually hidden in page or visible in page (can be read by screen readers) and can be hash linked, then an anchor tag might be appropriate (this case is not so common, eg: use case is if you are highlighting a paragraph or image on the page as a modal).
In almost all other cases, your modal is loaded on the same page and is in no way navigated using a url link (except through ajax for accessing data possibly, which doesn't count). Hence it is a custom functionality and a button is the appropriate choice.
Sort of by definition, a dialog is something that will pop up over the current window. You're not really leaving the window, it's just temporarily unavailable. Once you're done with the dialog, you typically go back to the window. So in that respect, you don't want to use a link because you're not going to another page. You're doing some action on the current page. Use a button.
When using a screen reader, I will often bring up the list of links (Ins+F7 in JAWS) to see what pages I can link to. I'll also bring up a list of buttons (Ctrl+Ins+B) to see what actions are available on the page. I would expect the action to bring up a modal dialog to be in my button list.
I want to know, according to WCAG 2.0, in which cases the spacebar is used to interact within the page.
Is it use in the same cases as the enter key?
Should I provide the same function to the enter key and the spacebar?
Do not change the native behavior of controls. That can mess with users.
A hyperlink 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. If there isn’t more to scroll then the user just experiences nothing.
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).
I have a CodePen from another example that shows this: http://s.codepen.io/aardrian/debug/PZQJyd
If you are making something like a <div> clickable and trying to add keyboard interaction, then do not use a <div>. Use the right element for the purpose, which I briefly outline as:
Does the control take me to another page? Use an anchor (<a href>).
Does the control change something on the current page? Use <button>.
Does the control submit form fields? Use <input type=submit> or <button type=submit>.
As far as WCAG 2.0 it says specifically to use space bar only in 3 cases:
https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/
Checks the radio button with keyboard focus (this is a special case when using tab and no radio buttons have been marked as checked (https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224#kbd_general_ex).
It is recommended that the space bar be used for selection for Drag drop support (https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224#dragdrop)
Checkbox - Space bar toggles checkboxes, if the list items are checkable (https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224#listbox)
The WCAG only mentions a guideline:
"The TAB key moves keyboard focus to the widget, and other keys operate the features of the widget, typically cursor keys, Enter key and Spacebar. The actual keys are up to the developer, but best practices recommend using the same key bindings that are used to control similar widgets in common GUI operating systems like Microsoft Windows®, Apple OSX® and UNIX Desktops like GNOME and GTK."
Frankly its left to the user's interpretation, and based on what you are trying to implement, you would probably have to see the existing behaviour of similar components on popular tools/web sites/ browser behaviour and make a logical decision.