I managed to find the following in bootstrap docs when referring to an accordion.
Be sure to add aria-expanded to the control element. This attribute explicitly defines the current state of the collapsible element to screen readers and similar assistive technologies. If the collapsible element is closed by default, it should have a value of aria-expanded="false". If you’ve set the collapsible element to be open by default using the show class, set aria-expanded="true" on the control instead. The plugin will automatically toggle this attribute based on whether or not the collapsible element has been opened or closed.
Additionally, if your control element is targeting a single collapsible element – i.e. the data-target attribute is pointing to an id selector – you may add an additional aria-controls attribute to the control element, containing the id of the collapsible element. Modern screen readers and similar assistive technologies make use of this attribute to provide users with additional shortcuts to navigate directly to the collapsible element itself.
What accessibility tags should I use when making drop down navigation?
What accessibility tags should I use when making drop down navigation?
Applications can have accessible behaviours without the use of any special tag. And they can have bad behaviours with the use of ARIA.
The ARIA definition says:
ARIA defines a way to make Web content and Web applications more accessible to people with disabilities.
But the use, the misuse, the abuse of ARIA can't make accessible something which is not accessible by default.
For instance, yes aria-expanded or aria-haspopup seem to be a must have, but it won't get of any help without the correct handling of keyboard navigation (javascript), convenient clicking area (css), and : color contrasts, visual cues that this is a dropdown navigation, timing, information hierarchy, ...
The W3C offers an example of fly-out menu
Related
I'm trying to learn accessibility with WAI-ARIA and all this kind of stuff but I'm really lost, I went for the official documentations on W3C and MDN but couldn't have precise idea about how to proceed.
This is my Website (don't mind top left blue and red stuff, it's NVDA focusing).
I don't know yet if I'm on the right track, how to proceed and if it's good way or not but I would like, when entering in document, that when I press TAB key, it focuses on the tag and when I press TAB again, it goes down into the header, so here the navbrand, then navmenu and when I press TAB again while on navmenu, that it goes down into it. In fact, I would like a kind of tabulation navigation that will be able to focus on "every" important division (here : header, main, footer, each section of main, each card of section, each text of each card, etc...)
For know, to give you a visual hint of what's happening, when I'm at the document's root and that I press TAB key, it will directly go at first link of the navigation.
Could someone light my way ? Am I planning things good or not ? If yes, how to proceed ? (Even if not good, how to proceed ?)
Thanks a lot for your time.
N.B.: I've hearded that it's bad thing to use tab-index > 0 and tried tab-index = 0 and even -1 and it doesn't work and I don't know if it's bad practice or not because may corrupt the DOM order or I don't know...
It sounds like what you need is a good primer on keyboard accessibility.
The correct behavior for tabbing is to move focus through the interactive portions of the webpage (e.g. buttons, links, form inputs, etc.).
Tabbing generally does not and should not set focus on non-interactive sectioning elements (e.g. header, main, footer, nav, etc.) or on static content, like paragraphs, lists, divs, spans, etc.
If you want to improve accessibility of navigation on your page, then you may want to consider the following:
Using HTML5 elements that already have implicit ARIA roles mapped, where possible
Implementing landmark roles where implicit roles are not appropriate
Implementing skip links so that repetitive navigation can be bypassed
Ensure that your focus indicator is easily visible and not hidden by CSS
tabindex should typically be avoided unless you really know what you're doing and have a very good reason for using it. Generally, the reading order should follow the visual ordering of the page, which should also follow the DOM ordering.
Additional Resources:
Keyboard Navigation - WebAIM
Understanding Focus Order - WCAG 2.1
WAI-ARIA Design Patterns and Widgets
ARIA Features Not Currently Available in HTML5
In general, if you use semantic html (meaning you use a <table> element when you have a table, a <ul> when you have a list, an <h2> when you have a heading, etc), then you should not need any ARIA attributes. In fact, the first rule of ARIA is to not use ARIA.
ARIA should only be used to fill in gaps where either semantic html is not available or there's a reason you can't use semantic html (such as for styling purposes, you have to use a <div> with CSS rather than a native <button>).
However, most of your question was about tabindex, which technically isn't an ARIA attribute. Tabindex has been around for a long time. The doc on tabindex explains the 4 types of values:
no value
negative value
0 value
positive value
I won't explain the differences unless you need it because in your case you should not need tabindex at all. You don't want to make non-interactive elements keyboard focusable. You mentioned moving the focus to the header, footer, main, etc. None of those are interactive elements so they should not receive focus.
If your menu is using links (<a>) or buttons (<button>), then they will already be keyboard focusable with the tab key and tabindex won't be needed.
when entering in document, that when I press TAB key, it focuses on the tag and when I press TAB again, it goes down into the header
I'm not sure what you mean by "focuses on the tag".
In your screenshot, if real links are being used, then the "natural" tab order would be:
Accueil
Produits
Services
Contact
Découvir ce service
Découvir ce service
Découvir ce service
and you wouldn't need any extra code for it to work.
Is it always necessary to use role="link"within the a tag or no more because I use HTML5 mark up?
<nav>
HOME
ABOUT
CONTACT
</nav>
As you see they are just simple links, MENU ITEMS, no dropdowns, no complexity. so, should I remove the role attribute?
From MDN
Note: Where possible, it is recommended that you use a native
element rather than the link role, as native elements are more widely
supported by older user agents and assistive technology. Native
elements also support keyboard and focus requirements by default,
without need for additional customization.
I think it's unnecessary in this case, since your items are already links.
Can I use the same role attribute in different elements that share the same functionality?
For example, the same logo in different parts of a website, or multiple svg icons which are all role: button.
I read somewhere this is malpractise but I don't really know how to get around this without losing the accessibility of my website. Should I just change the roles to non-WAI ones like "button1", "button2"...?
There may be some confusion here between the id attribute, which is expected to have a value that is unique inside the HTML page, and the role attribute, which identifies the type of UI components.
If you have SVG icons that function as buttons, then role="button" is correct, regardless how many such buttons you have in a page. There is no rule that says you can only have one button in a web page. On the contrary; if you want to make accessible each SVG icon that functions as a button, then you should assign them role="button" and make them keyboard accessible.
While the list of ARIA role values is strictly speaking non-normative from the point of view of the HTML5 specification, making up your own role values does not make much sense. WAI-ARIA developed the "role taxonomy" based on what types of UI components are/were supported in existing accessibility APIs. This is the background behind the mapping between WAI-ARIA and accessibility APIs in the WAI-ARIA 1.0 User Agent Implementation Guide. "button" is a type of UI component that accessibility APIs commonly support. "button1", "button2" are not UI components that accessibility APIs support.
In short, giving your SVG icons attributes such as role="button1", role="button2" is a bad idea; use role="button" for each such icon that functions as a button.
I am modifying my website for blind people.
How can I achieve keyboard functionality, i.e., using Tab to navigate each and every link, menu, submenu etc.
If you use HTML as intended (e.g., a for links, button/input for buttons, etc.), you don’t have to do anything. The elements that need to be focusable are focusable by default.
If you need to change the tabbing order, use the tabindex attribute.
If you have something that needs to be focusable, but you don’t/can’t use an appropriate element (e.g., you use span instead of a for a link), then you have to take care that this element can also be used/activated with a keyboard. WAI-ARIA might become necessary to make your custom solution accessible.
I have been seeing the aria attribute all over while working with Angular Material. Can someone explain to me, what the aria prefix means? but most importantly what I'm trying to understand is the difference between aria-hidden and hidden attribute.
ARIA (Accessible Rich Internet Applications) defines a way to make Web content and Web applications more accessible to people with disabilities.
The hidden attribute is new in HTML5 and tells browsers not to display the element. The aria-hidden property tells screen-readers if they should ignore the element. Have a look at the w3 docs for more details:
https://www.w3.org/WAI/PF/aria/states_and_properties#aria-hidden
Using these standards can make it easier for disabled people to use the web.
A hidden attribute is a boolean attribute (True/False). When this attribute is used on an element, it removes all relevance to that element. When a user views the html page, elements with the hidden attribute should not be visible.
Example:
<p hidden>You can't see this</p>
Aria-hidden attributes indicate that the element and ALL of its descendants are still visible in the browser, but will be invisible to accessibility tools, such as screen readers.
Example:
<p aria-hidden="true">You can't see this</p>
Take a look at this. It should answer all your questions.
Note: ARIA stands for Accessible Rich Internet Applications
Sources: Paciello Group
Semantic Difference
According to HTML 5.2:
When specified on an element, [the hidden attribute] indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.
Examples include a tab list where some panels are not exposed, or a log-in screen that goes away after a user logs in. I like to call these things “temporally relevant” i.e. they are relevant based on timing.
On the other hand, ARIA 1.1 says:
[The aria-hidden state] indicates whether an element is exposed to the accessibility API.
In other words, elements with aria-hidden="true" are removed from the accessibility tree, which most assistive technology honors, and elements with aria-hidden="false" will definitely be exposed to the tree. Elements without the aria-hidden attribute are in the "undefined (default)" state, which means user agents should expose it to the tree based on its rendering. E.g. a user agent may decide to remove it if its text color matches its background color.
Now let’s compare semantics. It’s appropriate to use hidden, but not aria-hidden, for an element that is not yet “temporally relevant”, but that might become relevant in the future (in which case you would use dynamic scripts to remove the hidden attribute). Conversely, it’s appropriate to use aria-hidden, but not hidden, on an element that is always relevant, but with which you don’t want to clutter the accessibility API; such elements might include “visual flair”, like icons and/or imagery that are not essential for the user to consume.
Effective Difference
The semantics have predictable effects in browsers/user agents. The reason I make a distinction is that user agent behavior is recommended, but not required by the specifications.
The hidden attribute should hide an element from all presentations, including printers and screen readers (assuming these devices honor the HTML specs). If you want to remove an element from the accessibility tree as well as visual media, hidden would do the trick. However, do not use hidden just because you want this effect. Ask yourself if hidden is semantically correct first (see above). If hidden is not semantically correct, but you still want to visually hide the element, you can use other techniques such as CSS.
Elements with aria-hidden="true" are not exposed to the accessibility tree, so for example, screen readers won’t announce them. This technique should be used carefully, as it will provide different experiences to different users: accessible user agents won’t announce/render them, but they are still rendered on visual agents. This can be a good thing when done correctly, but it has the potential to be abused.
Syntactic Difference
Lastly, there is a difference in syntax between the two attributes.
hidden is a boolean attribute, meaning if the attribute is present it is true—regardless of whatever value it might have—and if the attribute is absent it is false. For the true case, the best practice is to either use no value at all (<div hidden>...</div>), or the empty string value (<div hidden="">...</div>). I would not recommend hidden="true" because someone reading/updating your code might infer that hidden="false" would have the opposite effect, which is simply incorrect.
aria-hidden, by contrast, is an enumerated attribute, allowing one of a finite list of values. If the aria-hidden attribute is present, its value must be either "true" or "false". If you want the "undefined (default)" state, remove the attribute altogether.
Further reading:
https://github.com/chharvey/chharvey.github.io/wiki/Hidden-Content
setting aria-hidden to false and toggling it on element.show() worked for me.
e.g
<span aria-hidden="true">aria text</span>
$(span).attr('aria-hidden', 'false');
$(span).show();
and when hiding back
$(span).attr('aria-hidden', 'true');
$(span).hide();