At work I have been optimizing one of the sites I have helped developed for one of our clients (I can't say who) for be ADA compliant using WAI-ARIA attributes. I've been wondering if it wouldn't just be easier to create a small JS library that does things like add "role=button" to anchors I've styled to look like a button, add "tabindex=0" to elements I want to be "tabable" etc.
I was wondering if it is a good practice to add in WAI-ARIA attributes with JS or is that frowned upon. Some accessibility evaluation tools won't run the page's JS when evaluating it so it will think these are pain points when they are really not.
this may be helpful Add ARIA inline or via script?
Also note that if you use role=button it needs to act like a button (i.e. provide appropriate keyboard interaction behaviour)
I think in the interests of progressive enhancement, it might be best to put all your ARIA inline and not rely on script to add it.
If there are other script errors, if the connection gets dropped, if there is a blocking script in the way, etc., then your library may not come into play and your efforts at remediation will be lost.
I'd also like to build on what Steve said above about using role=button on a link. Especially when you consider that a visual style (to make a link look like a button) is meaningless to a screen reader use (for whom many ARIA roles benefit). I addressed other keyboard interaction gotchas in more detail in another SO answer, but here is one to consider when you try to turn a link into a button:
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.
Also, I caution against putting a tabindex=0 an an element you want to be tabbable unless it is an interactive element. For example, do not put it on a heading (<h#>) just so someone can tab to it as screen readers (for example) already allow navigation by headings.
Related
I'm trying to add accessibility to my website, but I'm running into a weird issue with Firefox's accessibility scanner. I've put onclick and onkeydown handlers on my interactive elements, but onkeydown doesn't seem to be enough; Firefox is telling me "Focusable elements should have interactive semantics." The [Learn More] link provided in the notice sends me to this page, which recommends a keydown or keyup event handler... which is already in the code. What am I missing here?
Here's a sample code I used to test the issue:
<img
src="https://www.google.com/logos/doodles/2022/seasonal-holidays-2022-6753651837109831.8-ladc.gif"
alt="Google"
title="Google"
tabindex="0"
onclick="alert('Google')"
onkeydown="alert('Google')">
In Firefox 108's Developer Console, under the Accessibility tab, using "Check for issues" for all issues gives me a notice on this element, saying "Focusable elements should have interactive semantics." despite the fact that onkeydown is defined and performs the same action as onclick.
EDIT: This question is not a duplicate of What does "Focusable Elements Should Have Interactive Semantics" mean in a figure? because that question regards an incorrect use of the role and aria-label attributes in a link, whereas my problem (as explained by the answer I've marked as correct, thank you!) was completely missing the role attribute and better resolved by wrapping this in a button.
The key thing here in the error statement:
Focusable elements should have interactive semantics.
is the word "semantics".
semantics refers to what an element actually "means" or "does" in the context of the page. Specifically, we are talking about the role of an element as exposed to the operating system's underlying accessibility API. An img element (providing it as alt text as you have correctly given it) has default role img (which is obvious, I hope - that comes from the table on this page), which you can view in the ARIA specification. I won't quote anything from that as what's most important in this context is what's not there. Basically, an image is not expected to be interactive - unlike elements with different roles such as button.
If you were to actually test your page with a screenreader - something I would highly recommend every front end developer does with some regularity - you would see the problem. Yes, knowing how your application behaves, you can press a key and have the intended functionality happen. But there's nothing in your HTML that implies that anything interactive will happen here - it's just an image, they're not expected to be interactive. So a screenreader will not announce anything to the effect of "oh by the way you can click on this" (or press enter or whatever) (actually from memory NVDA says "clickable" for elements with click handlers - but other screenreaders such as Voiceover won't, so you shouldn't rely on this. Even knowing the element is "clickable", users without a mouse or who are unable to see where they're clicking will not know how to trigger this "click".).
The solution is to give your element the correct semantics. Since this does something when you click it, and that thing isn't navigation to a new page, it strikes me that the correct role would be button. So you could do this, adding the correct role attribute:
<img
src="https://www.google.com/logos/doodles/2022/seasonal-holidays-2022-6753651837109831.8-ladc.gif"
alt="Google"
title="Google"
tabindex="0"
onclick="alert('Google')"
onkeydown="alert('Google')"
role="button">
This would be a big improvement - I'd expect it to no longer bring up the error you're seeing, as well as to be much more usable to users with assistive technologies.
But, whenever you find yourself using a role which corresponds to an alternative HTML element - and in this case it will not surprise you to know that the button role is automatically applied to the HTML <button> element - you should ask yourself if there's any good reason why you can't just use the correct element.
Only you can answer that question, but I'd be very surprised if such a reason existed. At worst, using a <button> may change your styles, but I'm assuming you have control of the CSS so you can update that as needed.
You do still want the image there because that's seen by sighted users so screenreader users should be told about it the same. What I would do is wrap the image in a button, attach the onclick handler to that button, and remove both the tabindex and the onkeydown, because one of the nice things about using the correct HTML element is that browsers handle most of the behaviour for you, in this case making buttons be in the tab order and trigger their click effect whenever Enter or Space is pressed when focused.
So this would be in my opinion the best way to code this:
<button onclick="alert('Google')">
<img
src="https://www.google.com/logos/doodles/2022/seasonal-holidays-2022-6753651837109831.8-ladc.gif"
alt="Google"
title="Google"
>
<button>
and you should get everything you need, including being accessible "for free" (and the button having the image's alt text as its "accessible name"), and at worst just have to add/update some styles.
I am currently making a navbar and came accross the aria-expanded html attribute. I know of course that the element is used to let an element either expand or collapse. I could find very little information with regard to this and the W3C docs aren't that clear IMO.
Question
How does this attribute work exactly?
The aria-expanded attribute is simply a flag for the user agent. It
Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.
...where that indication is for the element's contents, or if aria-controls is also specified, for the target element.
You set its value to indicate what you've done to the page (e.g., you've expanded or contracted a section). It doesn't have any particular behavior associated with it, it's for letting the user agent know what's going on so it can interpret that for its audience (who may be vision-impaired and need some other indication that a section is/isn't expanded).
ARIA attributes are related to accessibility. In this particular case, it's to let users with assistive technology (e.g. screen readers) know whether an element is expanded or not. It does not have any native effect on the styling of the element, but you can target that with CSS attribute selectors: [aria-expanded="true"]. You can toggle the value with JavaScript as needed.
Aria attributes in general are used to make web applications accessible to people with disabilities. They are used primarily by screen readers to determine how to treat html elements.
The aria-expanded attribute provides information about whether an element is in an expanded or collapsed state.
For example, if you have a collapsible element which contains a text, then a screen reader would know that the text is not currently displayed on the screen when the aria-expanded attribute is set to true.
As mentioned here:
WAI-ARIA is a spec defining support for accessible web apps. It defines bunch of markup extensions (mostly as attributes on HTML5 elements), which can be used by the web app developer to provide additional information about the semantics of the various elements to assistive technologies like screen readers.
WAI stands for: Web Accessibility Initiative
ARIA stands for: Accessible Rich Internet Applications
Hope it helps
It depends on whether your anchor element or any other element is active,
Just like dropdown from bootstrap then
which color you wants to apply on the parent while it is on clicked state!
Instead of adding/removing my different sections to/from the DOM, I'm only hiding them with aria-hidden="true", and unhiding them if certain <a> toggles are clicked.
Reasons are performance and an easier noscript fallback. The order in the DOM is not the order in which the questions appear.
The result is a binary question tree (yes/no questions) in which the user clicks from one question to the next.
Now what would be a good solution to make screen readers read a section or at least continue reading it next after unhiding it?
Is there a way with live-region? Do screenreaders read elements that become unhidden in it? I thought aria-current might be appropriate? Or is it more an aria-expanded application?
Thanks for your help!
ARIA live regions are without question the correct way to handle this sort of problem.
By using the aria-live attribute on an HTML element, assistive technology will be alerted when content is changed in one of these areas. Your choice of attribute value will specify how quickly the change is announced (immediately, or at next graceful opportunity). The most common implementation is typically aria-live="polite".
This page outlines some pretty useful (and innovative) techniques for implementing live regions: https://terrillthompson.com/tests/aria/live-scores.html
We are trying to automatically check our web-application for accessibility. We are therefore looking for ways to automatically check if a certain DOM-Element having an onclick event or beeing an interactive element by definition (like a link, button, checkbox or similar) is accessible by keyboard (e.g. by pressing the TAB key multiple times).
Is there a good standard JS solution (or library) for this? If not, any hints on how this could be achieved in JS?
To simplify things, the solution would also work for us, if the elements that need to be accessible by keyboard must be known (e.g. by a list of CSS selectors).
I am writing an application in JavaScript (with JQuery). The application has a lot of functionality that the user needs to access quickly and possibly at the same time (you could think of it as a game, even though it's not a game) so I've set it up to use the keyboard. I've got a prototype of the system working (in Chrome, at least), but there is a problem in that when I press, for example, Ctrl-T, it opens a new tab. I would like to use this as part of my application to, for example, toggle some setting. In general, I would like to disable the Ctrl-key functionality of the browser. This goes for Alt and Shift, too. In a different way, I would also like to disable the browser's usage of the Tab key. Basically, I want my application to have complete control over the keyboard while it's being used (if they want to navigate away, they will still be able to do so with the mouse). I will add the caveat that I don't care about some of the less-common keys (F1-F12, Windows/Mac-Command, Menu, anything right of the Enter key) because my application mainly targets laptops and many don't have those keys, so they won't be used.
My question is, how can I disable this browser functionality with JavaScript/JQuery/DOM?
I understand that taking over browser functionality in this way this sounds very authoritarian, but it's actually quite necessary. From the prototype and some target-audience test users (my family) everyone has agreed that this was a good idea.
I've also considered moving my application out of the browser and writing it in some application language (probably Java), but I want to find out if this kind of functionality is possible in JavaScript before making that kind of switch. This is prototyping time, though, so every idea is still up for consideration!
Basically, you return false at the right time. See this: How to create Ctrl+Key shortcuts in Javascript.
I should add and say sometimes this doesn't work - it's up to the browser to allow this.
Also, it is sometimes possible to change e.which to another key, but again, this wouldn't always work.