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.
Related
For the HTML title attribute, Mozilla's docs mention...
Use of the title attribute is highly problematic for:
People using touch-only devices
People navigating with keyboards
People navigating with assistive technology such as screen readers or magnifiers
People experiencing fine motor control impairment
People with cognitive concerns
This gives me a seed of doubt whether I can innocuously use title all over the place.
Would the mere existence of title actually introduce problems for certain users?
Or put another way, is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?
I'm just trying to maximize my UX & accessibility optimizations to 110%.
I can conceive of three different problems that using title attributes can introduce for those various groups.
No access
Some users don't use technology that would display the title attribute. This isn't a problem is the title attribute contains information that isn't required to understand the content.
Physically getting in the way
A tooltip might cover up some other information when it is rendered. You can probably compensate for this with space. Don't cram everything together. Allow enough room on a hover target so a tooltip can render in empty space, or at least space that doesn't contain information about the element being hovered.
Interruptions
If you scatter titles in the middle of a sentence, then I expect some screen readers will interrupt the sentence to read the tooltip. This won't make it easy to understand the document if it happens a lot.
I wouldn't go overboard with them.
(Related, but less of an accessibility issue, if the titles duplicate information in the text, then it is going to be very repetitive and annoying).
That depends, as always. Usage of the title attribute is not harmful, but relying on it is.
To quote the HTML standard:
Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).
https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute
Mostly, title is used to implement the tooltip pattern, which is then not very accessible, as stated.
So if you provide that supplemental information by accessible means as well, the title attribute does most likely not harm.
“[…] is there any benefit using title other than for showing-supplementary-information-as-rudimentary-tooltips-for-mouse-users-that-hover-an-element?”
Well, the WCAG accept title attributes as a sufficient technique to explain abbreviations in an <abbr> element or to label form controls, even though actual technical support is not great.
To name <iframe> elements it is still the only documented sufficient technique
If you use it on <style> and <link> elements, it allows the browser to provide a style switcher.
<link rel="stylesheet" href="dark.css" title="Dark Theme">
See also The Trials and Tribulations of the Title Attribute
I am being asked to put checkboxes on a webpage that perform no resolution, in that they simply exist to be checked in the form of a checklist that could be printed. There would be no form submission, no buttons, no popups or collapses, and no actions resulting in the checking of the boxes.
I believe this would be against the grain for UX and potentially against accessibility rules. Are there any rules I can reference in the WCAG guidelines that would back me up?
A couple of things to consider:
If the checkboxes perform a function in that they allow the user to check off which items are completed, then they are there for a reason but it's a question of whether their purpose has been clearly communicated.
From what you describe, non-accessibility users would be getting the same non-functioning checkboxes that accessibility users get, so accessibility is less of a consideration here than UX design. Accessibility is concerned with providing an equivalent user experience and conveying the same information for assistive technology users as for non-AT users, so quoting a WCAG guideline won't really help if the design problem affects both AT and non-AT users.
With that in mind, the WCAG guideline that seems most relevant to me is 1.3.1 - Info and relationships. This guideline deals with preserving the relationship between page information and the semantic structure or layout of a page, so that the way a page is structured (including the components used) doesn't convey different things to AT and non-AT users.
A common failure of WCAG 1.3.1 would be something like using headings for presentational purposes, but it can apply to any component which has a semantic meaning that is different from the presentational meaning. In your case, using checkboxes as a presentational device could fall under that type of failure. See here: https://www.w3.org/WAI/WCAG21/Techniques/failures/F43
The situation is a bit unclear. The checkboxes are there to be checked, but there is no action that could result in them being checked. That seems to be a contradiction.
In any case, I believe it causes no accessibility issue to include checkboxes on a web page, regardless of whether they are in a submittable form. There could be good reasons to do so. For example, if there are 10 checkboxes and the instruction tells the user to check no more than 4 of them, a script could enforce that requirement. Whether the purpose is to let the user print the page, or save it as a PDF file, or send a PDF version by email, or think about a topic, checkable checkboxes can be useful, and I know of no basis for an inference that they must be submittable to a server.
WCAG 3.2 indicates that content should be provided in a predictable format (https://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20161007/consistent-behavior.html) and that subsequently when new a new tab is opened on a click that the user is made aware of this.
I have a webpage with a list of many links that open in a new tab. W3C recommends that either this is indicated in the link text or an indicator is provided on hover/focus. However, because of the extensive amount of links on the same page that require this, providing these options would significantly disrupt the design/UI. Are there are other less visually intrusive ways to achieve this conformance without providing a pop-up or text warning for each link?
Also, are there other accessibility issues related to opening new windows/tabs?
That may depend on the level of conformance you're trying to achieve. Most companies (and most country laws) require AA conformance. In fact, the guidelines say that AAA conformance should not be required.
Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.
However, that does not mean you shouldn't consider some of the AAA requirements. For example, having color contrast that's greater than 4.5:1 (1.4.6 Contrast (Enhanced)) or making sure your link text makes sense by itself rather than relying on the context around it (2.4.9 Link Purpose (Link Only)) are both great enhancements above AA conformance.
With regards to links opening in new windows, that falls under 3.2.5 Change on Request, which is a AAA conformance. So depending on the level of conformance you're trying to achieve, you might not have to conform to it.
If you only had a handful of links scattered throughout your site that opened in a new window, it would be nice to have a visual indicator that shows the link will open in a new window, and to convey that same information to screen readers. (See H83: Using the target attribute to open a new window on user request and indicating this in link text (HTML) as an example. You could also use an icon instead of text, but make sure the icon has the alt attribute or that you provide context to a screen reader via aria-label, aria-labelledby, or visually hidden text).
But if you do that, and then you have a page where most of the links go to a new window, the page might look cluttered with all the extra information. This is where you'd have to be careful. If you decide to have a general comment on that one page that says that all links open in a new window so that you don't need an icon next to each link, then you'd be failing WCAG 3.2.4 Consistent Identification, which is a AA requirement. That is, you'd have some pages with "new window" icons next to the links and another page without it.
So you need to decide if you want to indicate that a link opens in a new window (a AAA requirement) or not. As mentioned earlier, implementing some AAA requirements is a good thing. Just be consistent.
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.
What is HTML5 ARIA? I do not understand how to implement it.
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. Of course, for ARIA to work, the HTTP user agent that interprets the markup needs to support ARIA, but the spec is created in such a way, as to allow down-level user agents to ignore the ARIA-specific markup safely without affecting the web app's functionality.
Here's an example from the ARIA spec:
<ul role="menubar">
<!-- Rule 2A: "File" label via aria-labelledby -->
<li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
<ul role="menu">
<!-- Rule 2C: "New" label via Namefrom:contents -->
<li role="menuitem" aria-haspopup="false">New</li>
<li role="menuitem" aria-haspopup="false">Open…</li>
...
</ul>
</li>
...
</ul>
Note the role attribute on the outer <ul> element. This attribute does not affect in any way how the markup is rendered on the screen by the browser; however, browsers that support ARIA will add OS-specific accessibility information to the rendered UI element, so that the screen reader can interpret it as a menu and read it aloud with enough context for the end-user to understand (for example, an explicit "menu" audio hint) and is able to interact with it (for example, voice navigation).
ARIA stands for Accessible Rich Internet Applications.
WAI-ARIA is an incredibly powerful technology that allows developers to easily describe the purpose, state and other functionality of visually rich user interfaces - in a way that can be understood by Assistive Technology. WAI-ARIA has finally been integrated into the current working draft of the HTML 5 specification.
And if you are wondering what WAI-ARIA is, its the same thing.
Please note the terms WAI-ARIA and ARIA refer to the same thing. However, it is more correct to use WAI-ARIA to acknowledge its origins in WAI.
WAI = Web Accessibility Initiative
From the looks of it, ARIA is used for assistive technologies and mostly screen reading.
Most of your doubts will be cleared if you read this article
http://www.w3.org/TR/aria-in-html/
What is it?
WAI-ARIA stands for “Web Accessibility Initiative – Accessible Rich Internet Applications”. It is a set of attributes to help enhance the semantics of a web site or web application to help assistive technologies, such as screen readers for the blind, make sense of certain things that are not native to HTML. The information exposed can range from something as simple as telling a screen reader that activating a link or button just showed or hid more items, to widgets as complex as whole menu systems or hierarchical tree views.
This is achieved by applying roles and state attributes to HTML 4.01 or later markup that has no bearing on layout or browser functionality, but provides additional information for assistive technologies.
One corner stone of WAI-ARIA is the role attribute. It tells the browser to tell the assistive technology that the HTML element used is not actually what the element name suggests, but something else. While it originally is only a div element, this div element may be the container to a list of auto-complete items, in which case a role of “listbox” would be appropriate to use. Likewise, another div that is a child of that container div, and which contains a single option item, should then get a role of “option”. Two divs, but through the roles, totally different meaning. The roles are modeled after commonly used desktop application counterparts.
An exception to this are document landmark roles, which don’t change the actual meaning of the element in question, but provide information about this particular place in a document.
The second corner stone are WAI-ARIA states and properties. They define the state of certain native or WAI-ARIA elements such as if something is collapsed or expanded, a form element is required, something has a popup menu attached to it or the like. These are often dynamic and change their values throughout the lifecycle of a web application, and are usually manipulated via JavaScript.
What is it not?
WAI-ARIA is not intended to influence browser behavior. Unlike a real button element, for example, a div which you pour the role of “button” onto does not give you keyboard focusability, an automatic click handler when Space or Enter are being pressed on it, and other properties that are indiginous to a button. The browser itself does not know that a div with role of “button” is a button, only its accessibility API portion does.
As a consequence, this means that you absolutely have to implement keyboard navigation, focusability and other behavioural patterns known from desktop applications yourself. You can find some Advanced ARIA techniques Here.
When should I not use it?
Yes, that’s correct, this section comes first! Because the first rule of using WAI-ARIA is: Don’t use it unless you absolutely have to! The less WAI-ARIA you have, and the more you can count on using native HTML widgets, the better! There are some more rules to follow, you can check them out here.
What is ARIA?
ARIA emerged as a way to address the accessibility problem of using a markup language intended for documents, HTML, to build user interfaces (UI). HTML includes a great many features to deal with documents (P, h3,UL,TABLE) but only basic UI elements such as A, INPUT and BUTTON. Windows and other operating systems support APIs that allow (Assistive Technology) AT to access the functionality of UI controls. Internet Explorer and other browsers map the native HTML elements to the accessibility API, but the html controls are not as rich as the controls common on desktop operating systems, and are not enough for modern web applications Custom controls can extend html elements to provide the rich UI needed for modern web applications. Before ARIA, the browser had no way to expose this extra richness to the accessibility API or AT. The classic example of this issue is adding a click handler to an image. It creates what appears to be a clickable button to a mouse user, but is still just an image to a keyboard or AT user.
The solution was to create a set of attributes that allow developers to extend HTML with UI semantics. The ARIA term for a group of HTML elements that have custom functionality and use ARIA attributes to map these functions to accessibility APIs is a “Widget. ARIA also provides a means for authors to document the role of content itself, which in turn, allows AT to construct alternate navigation mechanisms for the content that are much easier to use than reading the full text or only iterating over a list of the links.
It is important to remember that in simple cases, it is much preferred to use native HTML controls and style them rather than using ARIA. That is don’t reinvent wheels, or checkboxes, if you don’t have to.
Fortunately, ARIA markup can be added to existing sites without changing the behavior for mainstream users. This greatly reduces the cost of modifying and testing the website or application.
I ran some other question regarding ARIA. But it's content looks more promising for this question. would like to share them
What is ARIA?
If you put effort into making your website accessible to users with a variety of different browsing habits and physical disabilities, you'll likely recognize the role and aria-* attributes. WAI-ARIA (Accessible Rich Internet Applications) is a method of providing ways to define your dynamic web content and applications so that people with disabilities can identify and successfully interact with it. This is done through roles that define the structure of the document or application, or through aria-* attributes defining a widget-role, relationship, state, or property.
ARIA use is recommended in the specifications to make HTML5 applications more accessible. When using semantic HTML5 elements, you should set their corresponding role.
And see this you tube video for ARIA live.