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>.
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.
Right now I am setting the focus on the very first editable input field, during page load.
In terms of page accessibility, If the very first element is "read-only" input field then is it valid or meaningful to set the focus on the input field with cursor disabled ?
The question you should be asking is should you interfere with the user focus at all?
You may think it useful to automatically focus the first input (whether it is read-only or not) but this may not be as useful as you think.
When the page loads the user is expecting to have to use your skip link (I assume you have one, if not add it) to bypass the menu and get to the content of the page. However they may not want to as they may want to check they are on the correct page through breadcrumbs, menu position (assuming you mark the current page in some way) etc.
I am also assuming you have a <H1> on the page to reinforce that they are where they think they are on the site so they would expect to see that also.
If they are filling in a multi-page form then they will use screen reader shortcuts to look for the next form, if you have more than one on the page (search box, quick contact etc.) they would end up navigating away from your form by mistake instead of landing on it.
Now assuming that even with all of the above it is actually a better user experience to focus the first input (I am not saying it isn't, just pointing out the above considerations) should you focus the first 'read-only' input.
The answer is nearly always yes.
If a non screen reader user will see that information before they see information that requires inputting / editing then a screen reader user should also see it first.
The only exception to this would be if all of those read-only fields are a summary of everything entered so far in a multi part form.
In that case (as a rough rule, yet again use your own judgement) you should still provide that information first but make sure there is a heading / legend / field set title etc. that indicates that this is previously entered information and provide an easy way to skip to the fields that require input.
It is perfectly acceptable to have 'skip links' within the document, they don't have to just be for menus.
You do this so that they have the option to check previously entered information is correct and know it is available on the page to refer back to, but also don't have to tab past every single field if they don't want to check the information entered previously.
As with everything in accessibility, each use case is slightly different so the only real answer is 'it depends', but hopefully the above will help guide your thought process on what will work best.
This is where user testing is your best friend, only real world screen reader users who do not know your site design and layout will let you see if you made the best choice / which scenario works best.
Can someone advise me if there is a specific WCAG 2.1 failure when buttons are used as links. Same question vice versa. Links as buttons.
I have a site i am working on where by design there are links that appear the same as the buttons do.
So you may have buttons <button> like:
Edit details - which takes you to a new page where you can edit items in the page where the "edit details resides".
Continue - a button that takes you to the next page in a series of pages.
But then have links <a> which appear as buttons, so the same style, but they are labelled select, select and selected and these are a product type, so do not link anywhere.
Another example is the back link is a button<button> but looks like a link (text with underlined style)!
I know that this behavior confuses voice recognition as the user says click link or click buttonand not all objects get flagged that appear the same.
My question is does this fail WCAG2.1 specifically? Would this fall under 4.1.2 Name, Role, Value?
The 4.1.2: Name, Role, Value undestanding addresses the case of elements having different role than usual.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
As Adam already cited, "additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies". So yes, this fails WCAG 2.1, unless you take measures to ensure that your button-links and link-buttons really work as they are supposed to for example that a <a role="button" […] can be triggered using the Space key.
If you really have accessibility in mind, don't mix <button> and <a> elements up. Not even if you think you are smart and add role="button" to a link or role="link to a button. You would have to do more than that to make them behave like each other (see MDN about the button role).
And even then you should consider this: links are for navigation, buttons for performing actions. If you have a navigational element that looks like a button, its behavior might be confusing (even if it has no role="button" attribute). Also note that the default value for a button's type attribute is submit ("The missing value default and invalid value default are the Submit Button state.").
Web accessibility should encompass all disabilities that affect access to the Web and there are a lot of possible disabilities – and having one disability does not necessarily mean a person has no other disabilities.
The easiest step of making your website more accessible is to stick to the standards. Don't change an element's behavior unless you really have to (and even then: do you really have to?).
Update: General comment about WCAG and accessibility:
Web accessibility is also not just about simply conforming to guidelines like the WCAG. Even the WCAG itself does not claim that a website will be 100% accessible when conforming to it:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.
Update: Examples of possible violations of WCAG 2.1 (with room for interpretation though)
Just letting links look like buttons and nothing could be failing:
Guideline 3.2 Predictable in general ("Make Web pages appear and operate in predictable ways.")
Success Criterion 3.2.4 Consistent Identification (unless all links look like buttons; the only actual success criterion in these examples)
4. Robust in general ("Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies." & Guideline 4.1 Compatible "Maximize compatibility with current and future user agents, including assistive technologies." --> you already mentioned voice recognition and the possibility of not being able to target a link because it looks like a button)
Jonathan Pool wrote a blog article about this issue in which he points out another possible violation:
Worst case: A button that takes an irreversible action ("Yes, I confirm that I am waiving my rights.") pretends to be a link, so the user tries to use SPACE or SHIFT-SPACE to scroll the page but unexpectedly presses the button. This, arguably, would violate Web Content Accessibility Guidelines 2.1 Success Criterion 3.3.4.
I am creating a search form that has two elements an input field and a button. The input field does not have an label associated with it.
To make the field more accessible I can add <label for="searchfield">Search</label> and visually hide it so it will e.g. be accessible for screenreaders.
I could also add aria-label="search" to the input field and leave the input field without an label.
I have tested with "Voice Over" on a Mac and I get the same result/output. My question is are these approaches equivalent? Or is one approach better than the other one?
Here is a pen.
In the absence of having any knowledge of the site (how are other form fields labeled?) or the audience (what is their skill level or tech profile?), I approach these questions with a couple parameters:
The rules of ARIA (the first rule may apply here)
Progressive enhancement
That being said, I often code a page without ARIA and without CSS (as that may get blocked, chunked, etc) and make sure it is accessible.
That means I code a <label>. Then I visually hide it. If the CSS breaks, all is still well. If the user's screen reader does not support ARIA, all is still well. As an aside, if you think all screen readers of your users support ARIA, I encourage you to do to a tech assessment of users (local blind associations are a good start in the absence of any real users). Many people still run older versions of browsers and SRs.
For sighted users, I make sure I lean on contextual clues, like a clear search icon (or the word) in the button (as Unor references). Or maybe a placeholder with appropriate contrast (though you could use the <label> as a visual placeholder with some CSS trickery to hide it on focus).
If your submit button uses SVG, then I would be folding ARIA into that given the inconsistent support around SVG alternative text methods.
FWIW, I am also not a fan of the title attribute, partly because of inconsistent accessible name calculation and partly because I think it looks meh.
So, to answer your questions:
My question is are these approaches equivalent?
No, but the distance between them is shrinking.
Or is one approach better than the other one?
That depends on context we do not have.
Using aria-label is preferable to relying on CSS to visually hide a label element.
(Related Technique: Using aria-label to provide an invisible label where a visible label cannot be used)
But note that you don’t have to provide a label for a search form that only consists of the search field and the submit button. Assuming that you use a button labeled with something like "Search", it already makes clear which purpose the text field has.
(Related Technique: Using an adjacent button to label the purpose of a field)
In that case, while it doesn’t need a label, it should still get a name. One way to provide a name is to use the title attribute on the input element. The Technique Using the title attribute to identify form controls when the label element cannot be used shows this (a search form without label, with title attribute on input) in example 3.
I believe that aria-label="search" is the correct approach, as it produces cleaner markup (i.e. no unnecessary label tag) and no need for CSS to set visibility of the label - like in this example.
I believe visually hiding a label using CSS is a somewhat 'hacky' way to approach the problem, whereas ARIA is the standard for accessible markup, so it should be the obvious choice for situations like this.
On the other hand, it would be worth ensuring all browsers you intend to support can use ARIA correctly, and if not, it may be worth using the label approach to ensure compatibility across all browsers. Although, I think the support these days is pretty good, so that should not be a common scenario.
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.