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!
Related
According to the WAI guidelines for tabs, one should set the role tabpanel on each element that contains tabbed content and then set its triggering tab's aria-controls value to the container's ID.
This would work well in a situation where all tabs are included in the DOM and only hidden using CSS.
However, in my application I am only adding the currently selected tab's content to the DOM using JavaScript. This means that there will only be a single tabpanel in the DOM and all other tabs would have aria-controls values set to non existing IDs, which I doubt would be good practice.
So now I'm wondering: Should I set the tabpanel role at all or should I rather just set aria-controls from the tabs on the container that will end up displaying whatever tab is currently selected while adding aria-live="polite" and aria-relevant="all" to it or is there a better practice for this situation?
It‘s ok to omit the aria-control attribute, and the tablist shoupd be placed right before the tabpanels.
Conformance
From the ARIA specification on role tabpanel:
Authors SHOULD associate a tabpanel element with its tab, either by using the aria-controls attribute on the tab to reference the tab panel, or by using the aria-labelledby attribute on the tab panel to reference the tab.
So you can skip the aria-controls part and still be compliant.
Practical Implications
Since most screen readers don’t make anything of aria-controls right now, the best practice became simply keeping tablist and tabpanel closely together, with no contents in between.
Also from the specification:
tablist elements are typically placed near, usually preceding, a series of tabpanel elements. See the WAI-ARIA Authoring Practices for details on implementing a tab set design pattern.
This way users know to simply continue reading after changing tab, and to go back up from a tab panel to change tab. In most articles I read, this is highly recommended.
Of course we should not skip indicating semantics just because implementation is not there yet (e.g. as most developers did with inputmode). But if it poses an issue in your case, you can omit the aria-controls attribute.
I've been searching around for a more definitive answer but it seems that what I've uncovered has been out of date or the forum has a dispute as to the correct answer.
I'm building a react web app without bootstrap. Where is it appropriate to use alt vs title vs aria-label properties?
*From what I've gathered:
a and Link tags use title and aria-label
img tags use alt and aria-label
button tags use title
Attribute aria-label is used in the context of interactive elements that can be clicked or manipulated in some ways.
This is especially the case for links, buttons, and form elements, as well as elements that have been made artificially focusable with tabindex=0.
If the element you are trying to label isn't interactive, not focusable, you are better recommanded to use visually hidden text instead of aria-label.
The former is much more universally recoghized, while the later isn't guaranteed to be read in the case of a non-interactive element.
The alt attribute is specific for images, i.e. <img> tag, as well as image buttons <input type="image">.
Everywhere else, it doesn't exist. It is usable both for interactive and non-interactive images.
Avoid using alt and aria-label on the same focusable element to avoid any possibility that one is announced but not the other (in general one totally replaces the other).
The title attribute is less recommanded nowadays, because its support is extremely variable depending on the running screen reader and browser, as well as on which element it is used.
It still often works at many places though, especially links and form elements.
Again, avoid using both title and aria-label on the same element to avoid any possibility that one is announced but not the other (in general one totally replaces the other).
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
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.
I have decided to try and make my websites more accessible to screen readers and other assistive technologies. At the moment I'm really focussing on my navigation. Because who wants to iterate through all the items on a menu if the item you really want is nested deep and near the end?
So the website I'm working on has an entirely CSS-based dropdown menu which I am augmenting with javascript to make it keyboard accessible and adding aria attributes to help screen readers.
My question is
Given that my existing menu is pure CSS, I want to know if I now need to augment my menus with javascript to update the aria-hidden attribute whenever a part of the menu becomes visible? Or is it enough to set it to aria-hidden="true" in the first instance and leave it that way just to indicate the default state to the screen reader?
It just doesn't sit well with me that anything that uses pure CSS to show/hide content now needs to be augmented with javascript - it feels like it defeats the whole purpose of pure CSS display toggling.
Yes, you must set aria-hidden as its state changes.
Authors MUST set aria-hidden="true" on content that is not displayed, regardless of the mechanism used to hide it.
aria-hidden specification
That wording suggests to me that whether you use CSS or javascript to toggle visibility, you need to update the aria-hidden value.