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).
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 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
Right now my autofocus is on an input that doesn't provide much information for a screenreader... the screenreader would be much better for the visually impaired if it automatically read out the h1 tag on my page. I tried adding an autofocus attribute to my h1 but it didn't do anything. Do I have to do it with javascript?
If you really want to do that (I have the same case as you in a modal) you can add a
tabindex="-1" with your auto focus like that
<h1 mat-dialog-title tabindex="-1" autofocus>Modal name</h1>
The tabindex attribute explicitly defines the navigation order for focusable elements (typically links and form controls) within a page. It can also be used to define whether elements should be focusable or not.
[Both] tabindex="0" and tabindex="-1" have special meaning and provide distinct functionality in HTML. A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as , , and you understand now ) to receive keyboard focus. Of course one should generally use links and form controls for all interactive elements, but this does allow other elements to be focusable and trigger interaction.
A tabindex="-1" value removes the element from the default navigation flow (i.e., a user cannot tab to it), but it allows it to receive programmatic focus, meaning focus can be set to it from a link or with scripting or autofocus. This can be very useful for elements that should not be tabbed to, but that may need to have focus set to them. like in your case :)
More info: http://webaim.org/techniques/keyboard/tabindex
I recently ran into a similar situation, the Adrien Delabie's answer is partially correct but as it notes you have the problem that this removes the h1 from the navigation flow of the document.
That's bad.
Furthermore while giving something a tabindex makes it focusable VoiceOver (at the time of this writing) ignores non natively focusable elements when focused programmatically.
So I make an element like this
<h1>{{normalHeader}} <a id="specialfocusable" tabindex="-1">{{focusText}}</a> </h1>
Obviously when we decide to focus we focus on the #specialfocusable a element, but first we set the normalHeader to be an empty string and focusText to be the text we want the screen reader to read.
Voiceover reads it, the h1 is still in normal document flow so you can normally tab to it. (I have not had the chance to check in other screenreaders but I believe it shall work, at worst I need to handle a lose focus on the #specialfocusable and set normalHeader back and set focusText to empty string again), the a element is not read unless focus set on it with the focusText.
Of course you should also style the a so it does not look like an a, the same thing would work for any focusable element. Just an a element is the easiest to style.
All else being equal, an h1 can't be focused at all. It doesn't make sense to focus it anyway: It isn't an interactive element. You don't expect clicking on a heading to do anything (as you would if you clicked on a link, button, or input).
If you don't want the focus to interfere with reading the page in a normal linear fashion: Don't override the focus at all. Then the browser will start at the top of the page.
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.