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.
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.
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
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();
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>.
I just noticed that, in soundcloud, the "action" buttons on a track (like, repost, etc...) are all html button tags. Moreover, they are neither inside a form nor they bind to a form a la html5 nor submit a form (they apparently are being handled through javascript). Is this valid HTML? Can a button exist without a form? Or does that just make these buttons plain clickable divs? And how valid/unvalid would that be for screenreaders?
A button element is valid anywhere in the document body where text-level markup may appear. Such an element need not have any relationship to a form element. The currently authoritative reference is the HTML 4.01 specification, and the formal rules are in the DTD, but you can take a shortcut and use the W3C Markup Validator to check whether a document is valid.
When not associated with a form, a button element is not very different from a span element (rather than div, which is block-level by default), but button has special default rendering. Browsers and assistive software may treat button as otherwise special too, and it is safest to use button only for elements that are supposed to trigger some action when clicked on. Conversely, such elements are often best represented using button markup, though you can create visually button-like elements in other ways too (images or CSS, mostly).
Outside a form, a button element has type=button as default (and that’s normally the only sensible type for it then). This means that it can only have an effect via JavaScript. This does not make it invalid in any way. However, you may consider generating such buttons via JavaScript instead of having them as static HTML content, so that when scripting is disabled, there won’t be a (valid, but) confusing button that does nothing.
To address clarifying questions in the comment below:
A button type=button element is similar to input type=button; the difference is that the latter has no content but takes the text shown in the button from the value attribute, whereas button has content that can be “rich” (with markup).
For either element, if using them causes a server action (typically, via an Ajax call), then we can indeed ask how the page works with JavaScript disabled. But this question might be irrelevant (perhaps the page is an application that is supposed to run with JavaScript anyway), and in any case there is nothing formally wrong with the idea.
Why do they exist? For author convenience and for legacy reasons, I would say. Similarly, one might ask why HTML has event attributes at all, when they cannot possibly work without client-side scripting and you can assign event handlers to elements in JavaScript. But in the early days, that was not possible, and even at present, it might be more convenient to use the button element or the onclick attribute than to do things in JavaScript (and, for making an element look like a button, CSS). There is also the point that button and input type=button create browser-dependent appearance for elements, and it might be argued that for most users, anything that has the style of his browser’s default style for buttons is perceived as a button.
Yes. Since a very long time.
From whatwg.org :
Contexts in which this element can be used:
Where phrasing content is expected.
In the era of ajax, most inputs aren't just send by submitting a form. And most buttons are just used to execute an action on click while using a recognizable widget.