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.
Related
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.
In most cases there doesn't seem to be any visual indication which must be difficult for users who rely on the keyboard.
This seems a really simple question but I've scoured the internet and can't find an answer. My first idea was to use Firefox's developer tools to create a visual indication using *some element*:focus {outline: 2px solid red;} but of course you'd need to already know which element was receiving focus for that to work, so I tried the universal selector *:focus {outline:2px solid red;} but that didn't work.
So can anyone answer the seemingly simple question of what element is gaining focus ... and for bonus kudos can anyone provide a code snippet that would allow me to actually see what is happening?
In the case of a modal dialog box, the focus should go back to where it were before the box appeared.
For example, if the dialog box appeared upon clicking a button, the focus should return to that button when the dialog is closed, regardless of how it has been closed (mouse click or enter on a close button or escape key).
The most keyboard accessible apps and websites are those where you always know where the focus is. The blur function must be banned; it should never have existed.
It depends on the implementation where focus goes after closing the dialog.
However, the WAI-ARIA best practices for keyboard interaction state the following for dialog in a note:
When a dialog closes, focus returns to the element that invoked the dialog […]
In other words, the link or button that opened the dialog is focused.
I checked the native implementation of the HTML <dialog> element in Firefox and Chrome.
Chrome 78: After leaving the dialog by means of the escape key, focus is set back on <body>.
Firefox 71: Did not implement any focus logic yet. Focus is not limited to the dialog, neither is it put anywhere else after the dialog closes.
For all other UI libraries there is different ways to implement the dialog, which will result in different elements being focussed after closing:
1 Conditional rendering: The dialog doesn't even exist in the DOM if it's not visible
2 Hiding the dialog via HTML hidden=true or CSS only display: none
In case 1 focus will be set on <body> in Chrome and Firefox.
In case 2 both browsers keep the focus on the element inside the (now hidden) modal.
If accessibility is a concern, the evaluation of different libraries should take that into account.
While doing research I came across this statement:
Warning: Be careful when marking up links with the button role.
Buttons are expected to be triggered using the Space key, while links
are expected to be triggered using the Enter key.
Does anyone know why a different key is used for buttons / links?
Is it ok to trigger using both Space and Enter?
Before reading this I, as a user, would have had no idea when to use Space or Enter.
Had a quick look at Google to see what they do.
For links Space scrolls down and Enter triggers
For buttons both Space and Enter trigger
Buttons are form elements.
If you select a checkbox element, space will toggle the checkbox while enter will submit the form.
So to be coherent, buttons act the same way. In practice, they accept both enter and space without any difference.
It is not only ok but you have to
Read inside the Third rule of ARIA:
For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.
This is for historical reason, not that it has been defined in any official recommendation, as far as I know
For instance an old bug from 2000 (https://bugzilla.mozilla.org/show_bug.cgi?id=56495) already stated that space bar was expected to work on buttons. Maybe an inheritance from Windows behavior.
I am speculating to answer #1, but I believe the keys used to activate buttons versus hyperlinks are holdovers from operating systems. For hyperlinks, think of Windows Help in Windows 95 and its reliance on in-content links, or Hypercard on the Mac prior to that. Also note that Space has scrolled a page in browsers since (IIRC) day one.
To answer number 2, no it is not OK. This is because a space bar triggers a page scroll and many users expect that when focus is on a hyperlink that pressing Space will just scroll the page.
In short, honor the keyboard mappings that are in place since there are users who rely on them and messing with them can have catastrophic consequences for users of assistive tech along with users with disabilities who do not use assistive tech.
Let me re-state what you saw at Mozilla:
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.
And then let me add this:
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).
Source: Links, Buttons, Submits, and Divs, Oh Hell.
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 manage several websites that use a featured article scroller on their homepages, which allows the user to click a forward or back arrow in order to see the next article headline and blurb while remaining on the same page.
I use WAVE's accessibility checker and any sites that have this particular plugin throw an error back because within the code there is an empty link, written as <a href="#">. Is there any way around this? I've defined a title attribute but the # is causing the empty link error to still come up.
Some places I've seen that this is perfectly acceptable and others claim this is a problem. What's the actual answer and potential workaround?
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).
Some source suggests that link would be an invalid hypertext reference, but in fact the problem would exist only in non javascript browsers which is out of the scope of WCAG 2. This is not your problem here as this is not an error that WAVE considers.
The problem here is the fact that you have an empty link content and that adding a title attribute does not satisfy WAVE algorithm.
If your only concern is to satisfy WAVE, just put some content in the link and use any CSS trick to hide this content.