I just wanted to know if blockUI provide any support for differently-abled / blind users ?
For example, when loading spinner is visible on screen, an announcement should be made for screen reader users eg. 'alert loading content' or something similar.
Please let me if same is already implemented or not?
<span aria-live="assertive" id="" class="sr-only" role="alert" style="display:none;">something is loading</span>
this span should be shown if loading spinner is visible
Just using a demo, the plugin is not completely accessible. It would require extra work since the modal dialog does not properly handle all keyboard interaction at all. A user should be able to close the dialog with the Escape key. As well, clicking on the 'shade' area should close the dialog, and there's no close button for the pop-up. The user is forced into a choice.
Speaking to the animation specifically, I would suggest following the guidelines for timed media specific to video-only since there's an animation, and provide a clear explanation of the loader, but I would avoid using this method if at all possible. There are much clearer and cleaner methods for modals that are WCAG Compliant and still actively supported.
Time-Based Media: https://www.w3.org/TR/WCAG21/#time-based-media
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 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'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
I'm curious what's the proper way to push the screen read to read <span>read me on load</span> first (it's in the middle of the html page) when the page is loaded?
Even
role="rude"
doesn't help for some reason.
Thank you.
What you are using is not part of ARIA live regions. You want either role=alert or aria-live=assertive (though in an early draft "assertive" was originally "rude").
Now, that being said, live regions are intended for use on an already-loaded page. If you are making a dialog, then your HTML might look like this:
<div role="alert" aria-live="assertive">
Anything in here will be announced as soon as it changes.
</div>
If you want the dialog to be announced at page load, then consider hiding its contents and then using script to display its contents once the page has finished loading.
If you need to make it announce as soon as the page loads and it is not a dialog, consider moving focus to the element at page load using script. By placing focus, the browser will announce whatever it is.
For this to work, however, you cannot just place focus on a <span> as it is not interactive content. You can make it interactive by adding a tabindex attribute. If you do that, then you will need to add a role describing what the element does (you can use role=region if you are stuck) so that the screen reader can announce what it is instead making the user think she has landed on a control or otherwise expect to be able to take an action.
If you are moving focus to the element for users without screen readers, or if the very first thing the page displays at page load is an alert of some sort, then this should be fine.
However, since you have provided no context and no examples, and given all the ways this can be done that are far worse than doing nothing, please ask yourself this:
Is the thing you want to announce…
…an alert or dialog?
…a control that already can receive keyboard focus?
…going to be given focus for all users, not just those with screen readers?
If you end up saying no twice then you should not do this.
If you can provide an example URL that shows what you want to do, then I am happy to help you get it working. Otherwise I fear you may be coding something that ends up creating a trap or barrier for screen reader users.
I need to be able to have a popup, preferably like a lightbox that displays an html message when a user clicks a link. The popup will populate the screen and the user will have to click "OK" after reading the message. How can this be done using lightbox? I'd rather avoid using a boring prompt as its much less attractive.
http://lokeshdhakar.com/projects/lightbox2/
You might be able to do it in lightbox, but as far as I can tell it's not quite what lightbox was intended for. You may want to consider a more generic "modal" type of solution. A common one is jQuery UI's Dialog. Another common one is Bootstrap's modal solution.