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.
Related
Say I'm building a typical document editor:
Where the preview (in red) is an up-to-date, formatted vue of the form's data.
The preview element contains semantic elements (e.g. h1, h2, main, header, etc.). It's kind of a document in itself, which does make sense, conceptually. But this makes the structure of the real document quite confusing for crawlers and screen readers. There might be, for instance, two h1 or main elements. I'm looking for a way to avoid that.
Plus, there's the problem of repetitive content (see image).
For the accessibility part of the problem, I could just add an aria-hidden="true" attribute to the preview element. In fact, visually-impaired people don't need the preview, it's just redundancy to them, they just need the form.
But for crawlers, here are my options:
Don't use semantic elements inside the preview element, use divs instead (😥).
Host the preview at an other URL and insert it via an iframe (that's what I'm doing right now, but it seems hacky to me).
Leave it like that, crawlers don't care.
Any idea/resource/suggestion?
As long as your preview area is clearly indicated for assistive technology, it's perfectly fine to have redundant information. If you have an <iframe>, make sure there's a title attribute on it.
<iframe title="preview area"...>
However, you might have validator issues with multiple structure elements.
For example, HTML only allows one <main> element:
A document must not have more than one main element that does not have the hidden attribute specified.
You can have multiple <header> elements but a <header> has a default role of banner and the banner role says:
Within any document or application, the author SHOULD mark no more than one element with the banner role.
The key here is "should", meaning it's a strong recommendation but not required. You can also get away with multiple banner roles if your preview section has role="document".
I would recommend not using non-semantic elements (div) because an assistive technology user might want to check the actual semantic structure of what's generated, although I suppose you could also have a "show in new tab" option for the preview that uses all full semantics, kind of like your second bullet but not using an iframe.
I am using a html5 header element to display a logo inside the body. ANDI accessibiility compatibility is recognizing this as a landmark. I tried going thru the documentations but they only specifiy how to add landmark but do not mention how to ignore or remove an unwanted landmark.
How do I make header/any element in future a non landmark. Any attributes I could set or any directions would be helpful.
Note: I'd still like to be able to use header element.
If useful, its an angular application. Thanks in advance.
Don't use a <header> element.
It isn't about what you want it is about what people need in order to access your site correctly.
Semantics are really important for accessibility, especially for screen reader users and trying to rely on aria to override an elements semantic role is a bad idea.
Screen reader users navigate by landmarks and expect to see them in certain places, this is one of the main reasons it is important.
There is nothing wrong with using <divs> for things that do not form part of the document structure.
If you want to know what to use instead please add a fiddle / link to your question, just in case there is a more appropriate element with the correct semantics.
So if I need to do it for legitimate reasons.
Use role="presentation" as this converts an element to be treated like a <div> (which has no semantic role.). However as stated this should be used sparingly support for aria is not as good as you might think..
In striving for WCAG 2.0 Compliance, I'm finding quite a bit of varied information regarding proper treatment of buttons, specifically what is required to consider the button accessible and compliant.
What is the appropriate way to mark-up a <button>? What attributes or combination do they need to have?
My buttons fall into three categories:
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
For instance, in the following simple example of 3 above: http://codepen.io/ga-joe/pen/ggeLeW
Is it acceptable to add only an aria-label attribute for a button with no text? Are name and / or value always required? Please send help! Thank you!
These seem to be the relevant WCAG Guidelines:
https://www.w3.org/TR/WCAG20/#text-equiv-all
https://www.w3.org/TR/WCAG20/#navigation-mechanisms-refs
https://www.w3.org/TR/WCAG20/#ensure-compat-rsv
These kinds of questions always depend on context. Let me give it a shot sans context.
<button>Learn More</button> does the trick as long as contextually someone will understand what they will learn more about. Usually the button is preceded by some descriptive text. However, if it just brings someone to another page as opposed to firing a modal, I would use a link.
<button aria-label="Close">×</button> for a close button (I am using the character entity for ×, which is more symmetrical than x. Again, if the button is at the top of a modal (for example), perhaps adjacent to its heading, then that is probably adequate.
<button aria-label="Image 1">[icon]</button> can work for a carousel. Note that a font icon can be lost if the typeface does not download. A background image will disappear in Windows High Contrast Mode (WHCM) for IE11 and older versions of Edge. The aria-label will not help the WHCM users. Probably best to use an image (even an SVG) and its alt attribute instead, which means then you do not need aria-label.
You do not need a name attribute. It does nothing useful here.
Do not use a role="button" attribute. That role is automagically part of the <button> element. If you assign another role, then you have a big problem.
Definitely do not use a title attribute. That does more harm than good.
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
You can read the recommendations for WCAG 2.4.9 Link Purpose (Link Only) even if we're not talking about links. The text "Learn more" can be understood when in context, but for low vision users who require screen magnifier, for instance, it can be difficult to understand the action from the button text itself.
For instance the text Learn more about "Wheels on the bus" may seem more appropriate.
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
I answered that subject in another post:
What is aria-label and how should I use it?
You have to use both aria-label (useful for screenreaders) and title attributes (for standard users using standard browsers which may need more support):
<button
aria-label="Back to the page"
title="Close" onclick="myDialog.close()">X</button>
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
The same reasoning can apply to this point. But for blind people, moving a carousel to the left or to the right is a different experience, sometimes useless. If they can ignore that what they see is a carousel, without losing any content, navigating with the keyboard or their assistive technology, then you are doing what is expected.
Also, you have to never forget that accessibility does not only target blind users, but also children, old people, people with cognitive or sensitive disabilities. For instance, the aria-label will never be sufficient enough to help those people when needed. They do not have a screen reader, and they do not read the HTML source code.
In the case of users using "speech-recognition software" (yep, they are not a lot but let's improve their life), not having any visible text can also lead to difficulties.
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'm upgrading the HTML for a site, and there is currently a list of items presented as filters or refinements that are marked up as check-boxes with labels, but not in a form. Then for "SEO reasons" they added an <a /> tag that isn't wrapped around it:
<label>
<input type="checkbox" name="one" value="one" /> Refinement One
</label>
This is obviously not really adding full SEO value, and its kind of clunky HTML since the checkbox isn't necessary: the page works by listening for clicks on the label and firing an ajax load, all without a form. To be clear: there is no form, let alone a form submission, so the checkbox is there only as a visual cue. I want to replace it with background images on the anchor, and ditch the checkbox completely like the following:
Refinement One
<a class="checked" href="/url-for-adding-two">Refinement Two</a>
The client is cool with this, but their main concern is with accessibility and how this change would be reflected to screen readers... my personal thought is that it must be better than checkboxes without a form, but I want a better answer that my gut-check.
Do you know of any accessibility implications of replacing checkboxes with links in this situation?
If the page works by listening to clicks, then it in principle violates the accessibility requirement “Make all functionality available from a keyboard”. In practice, though, pressing Enter key in a focused element is generally treated as corresponding to clicking, i.e. a click event is triggered.
Checkboxes without a form are not a problem as such, never were. They can only work via client-side scripting, of course.
Using links might be related to history bookkeeping rather than SEO (because pages referred this way are seldom relevant in searches). If they are desired, then the choice is between making the control a link and duplicating it with a link. Duplication may cause confusion, especially in unusual browsing situations, so the link approach appears to be better. If the purpose of the link is to cause some action immediately, then it might be better to style it to look like a button. So a checkbox, even as a pure graphic, would appear to be unnecessary.
If it is necessary to show the user the options that have been taken (similarly to showing a checked checkbox), this could be done e.g. by showing a list of currently selected options (possibly along with buttons for unselecting).
The question is whether they end up looking like and behaving like checkboxes to sighted users. If these are items that visually appear to have a checked / unchecked state, and can have that state toggled by clicking, then they are behaving as checkboxes, so need to be exposed as such to screenreader users.
The problem with using plain anchors here is that the screenreader will just read them out as link elements, so a screenreader user will be expecting navigation to take place, not something that toggles state on a page. Also, no checked state information will be read out, so a screenreader user won't know if the item is checked or not.
The ideal situation here is to continue using real checkboxes, as in the original code. (Drop the empty A tag; it's a problem for keyboard users, as they can tab into it, but it has no screen presence - for sighted keyboard users - and has no content text, so screenreaders will just read out "link" leaving the user confused about what the focus is on.)
The advantages of using real input type=checkbox controls here is that they just work; sighted mouse users, sighted keyboard users and screenreader users all get good experiences. They are mouse and keyboard accessible; screenreaders will announce them as checkboxes, and convey the checked/unchecked state. (It doesn't matter that they are not in an actual HTML form.)
--
For what it's worth, if you did have some compelling reason to not use input type=checkbox and instead had to use an A that has been modified with click handlers and background images to behave as though it were a checkbox - and I don't think there's a good reason for going that route here! - then you could use the WAI-ARIA attributes to mark up the control with additional semantic hints so that screenreaders will announce it as a checkbox with correct state; this would involve adding role="checkbox" and aria-checked="true", for example. Also, since users expect checkboxes to respond to the spacebar as well as enter, you'd need to add keyboard handling for that also. And you'd need to test this with a screenreader to make sure it actually works. That's a lot of work to duplicate what input already does for you! This approach, however, does make sense when implementing custom controls that HTML does not already provide handy equivalents for, such as menus, sliders, treeviews and the like. Some of these will eventually - or are already - making their way into HTML anyhow.)
The correct answer here is to use ARIA, in particular the aria-checked attribute. It's designed specifically for accessibility.
That said, I think your desire to get rid of the checkboxes is misguided. Anything that acts like a checkbox---i.e., it has a checked state and an unchecked state, which controls something on the page---should probably be a real checkbox. This gives you very nice behavior in terms of not only screenreaders, but also what keyboard and mouse users expect.
You can always wrap the <a> around the <label>.