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.
Related
With HTML 'accesskeys' there is an effective way to increase the user's operating speed. In desktop applications, a user is shown the available shortcuts by underlining a letter of the operation to be performed. Transferring this concept to web applications leads to conflicts with
Web Content Accessibility Guidelines (WCAG) 2.0, Level A: 1.3.1 Info and Relationships.
<button onclick='javascript:alert("Click");' accesskey="C"><span style="text-decoration: underline;">C</span>lick</button>
or at CodePen. Testing this code snippet on tenon.io leads to an error referencing the WCAG guideline above. So the question is, how to highlight accesskeys in a way, that
it is valid with respect to WCAG
it is understood as an accesskey by the user?
Tenon.io actually provides this explanation for the snippet:
The text in this passage has been styled to display underlined but it is not a link.
So this, actually, applies more to 3.2.4
Consistent Identification.
In the end, for an audit, there always is room for interpretation of WCAG’s success criteria. It will be up to the auditor to decide.
While tenon.io’s warning is helpful in most cases, in your case I don’t think it applies, as links with single characters as text are very rare. Additionally, the context of the button makes clear that this cannot be a link. Context over Consistency, as we say in UX design.
If you are motivated, you can reach out to tenon.io and discuss the subject with them, maybe leading to an improved rule.
My team and I are building a web-app for a customer who has requested custom functionality pertaining to data-tables: upon clicking the header of a given table column, the table then becomes sorted based on that column. This functionality is already implemented.
However, an important stipulation of the contract is compliance with WCAG 2.1 accessibility standards. Aside from within tables, we have aria labels in all the right places, but it's unclear how we should go about making this custom table behavior more accessible-- particularly for screen-reading tech. As of now, the table header cells themselves have event-handlers for clicks to trigger the functionality, but no semantic <button>s are involved in this process, which is where things start to feel a little wrong for me.
The table header cells are also focusable, so that users can use Enter or Spacebar to toggle the functionality that way. How should we handle communicating this behavior to the user, especially those using screen-readers? Since this functionality is not typical of what is otherwise a fairly standard table, guidelines and requirements from WCAG and other sources are unclear.
I apologize, but I am unable to provide a screenshot or code snippet due to the sensitive and proprietary nature of the content.
For any table that is readonly and also is meant not to be sorted etc. standard HTML tables should be used.
In your case please use the design pattern grid from the ARIA 1.1 guideline (chapter 3.12 under this link https://www.w3.org/TR/wai-aria-practices/#grid)
Your customer should familiarize himself about the keyboard commands ARIA declares for grids. Manipulating theese keys will mean much work to you and irritating the screen reader user and hurt WCAG.
Here are two decent examples of accessible sortable tables:
https://assets.cms.gov/resources/framework/2.0/Pages/datatables.html
https://adrianroselli.com/2021/04/sortable-table-columns.html
The first one is a little too wordy with it's announcement to screen readers and could be shortened up for a better user experience and the second one is a little too terse with just saying "title button". We need a Goldilocks example between the two but both examples show how to use a <button> in the table header and the use of aria-sort.
I didn't hear anything in your OP that would indicate that a grid should be used. Note that the first sentence in the grid definition says that a grid is "a composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys." In other words, if the user will be able to navigate the table using the up/down/left/right arrow keys (as if you're navigating through a spreadsheet), then a grid is appropriate. But if you have a "normal" table that does not allow navigating cell by cell, then a standard <table> can be used. Just add buttons to your column headings (<th>) that allow the table to be sorted.
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 keep seeing role attributes in some people's work. I use it too, but I'm not sure about its effect.
For example:
<header id="header" role="banner">
Header stuff in here
</header>
Or:
<section id="facebook" role="contentinfo">
Facebook stuff in here
</section>
Or:
<section id="main" role="main">
Main content stuff in here
</section>
Is this role attribute necessary?
Is this attribute better for semantics?
Does it improve SEO?
A list of roles can be found here, but I see some people make up their own. Is that allowed or a correct use of the role attribute?
Any thoughts on this?
Most of the roles you see were defined as part of ARIA 1.0, and then later incorporated into HTML via supporting specs like HTML-AAM. Some of the new HTML5 elements (dialog, main, etc.) are even based on the original ARIA roles.
http://www.w3.org/TR/wai-aria/
While the First Rule of Aria states:
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
there are a few primary reasons to use roles in addition to your native semantic element.
Reason #1. Overriding the role where no host language element is appropriate or, for various reasons, a less semantically appropriate element was used.
In this example, a link was used, even though the resulting functionality is more button-like than a navigation link.
Delete
<!-- Note: href="#" is just a shorthand here, not a recommended technique. Use progressive enhancement when possible. -->
Screen readers users will hear this as a button (as opposed to a link), and you can use a CSS attribute selector to avoid class-itis and div-itis.
[role="button"] {
/* style these as buttons w/o relying on a .button class */
}
[Update 7 years later: removed the * selector to make some commenters happy, since the old browser quirk that required universal selector on attribute selectors is unnecessary in 2020.]
Reason #2. Backing up a native element's role, to support browsers that implemented the ARIA role but haven't yet implemented the native element's role.
For example, the "main" role has been supported in browsers for many years, but it's a relatively recent addition to HTML5, so many browsers don't yet support the semantic for <main>.
<main role="main">…</main>
This is technically redundant, but helps some users and doesn't harm any. In a few years, this technique will likely become unnecessary for main.
Reason #3.
Update 7 years later (2020): As at least one commenter pointed out, this is now very useful for custom elements, and some spec work is underway to define the default accessibility role of a web component. Even if/once that API is standardized, there may be need to override the default role of a component.
Note/Reply
You also wrote:
I see some people make up their own. Is that allowed or a correct use of the role attribute?
That's an allowed use of the attribute unless a real role is not included. Browsers will apply the first recognized role in the token list.
<span role="foo link note bar">...</a>
Out of the list, only link and note are valid roles, and so the link role will be applied in the platform accessibility API because it comes first. If you use custom roles, make sure they don't conflict with any defined role in ARIA or the host language you're using (HTML, SVG, MathML, etc.)
As I understand it, roles were initially defined by XHTML but were deprecated. However, they are now defined by HTML 5, see here: https://www.w3.org/WAI/PF/aria/roles#abstract_roles_header
The purpose of the role attribute is to identify to parsing software the exact function of an element (and its children) as part of a web application. This is mostly as an accessibility thing for screen readers, but I can also see it as being useful for embedded browsers and screen scrapers. In order to be useful to the unusual HTML client, the attribute needs to be set to one of the roles from the spec I linked. If you make up your own, this 'future' functionality can't work - a comment would be better.
Practicalities here: http://www.accessibleculture.org/articles/2011/04/html5-aria-2011/
Is this role attribute necessary?
Answer: Yes.
The role attribute is necessary to support Accessible Rich Internet Applications (WAI-ARIA) to define roles in XML-based languages, when the languages do not define their own role attribute.
Although this is the reason the role attribute is published by the Protocols and Formats Working Group, the attribute has more general use cases as well.
It provides you:
Accessibility
Device adaptation
Server-side processing
Complex data description,...etc.
I realise this is an old question, but another possible consideration depending on your exact requirements is that validating on https://validator.w3.org/ generates warnings as follows:
Warning: The form role is unnecessary for element form.
The role and other attributes improve the accessibility for screen readers. It can indirectly help search spiders identify and understand the individual section better. If I compare this and microdata schema, it improves SEO in a small way.
Role attribute mainly improve accessibility for people using screen readers.
For several cases we use it such as accessibility, device adaptation,server-side processing, and complex data description.
Know more click: https://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute.
"role attributes" are developed to help people who have vision or eyesight issue. Screen readers inform the user about the elements. Even though this seems an easy task but it is not. if you are not expert and not sure, do not assign a role. you can read from here
It is important to understand that sometimes poor ARIA implementation
can cause more problems than it can solve, making the content less
accessible. This can happen because of a lack of knowledge of how and
when to use ARIA.
Some HTML elements have implicit roles. For example:
h1,h2...h6 -> heading
ul,li -> list
button -> button
a -> link
<input type="text"/> -> text
You can override those, to be more descriptive
In the case of SEO, You can read the-accessibility-and-seo-myth/
A Google search for “Search engine ranking factors” displays a number
of results featuring leaders in the SEO/ SEM industry that outline the
many factors that improve SEO. The vast majority of the identified
ranking factors have no relationship of any kind with Accessibility.
In fact, even many of the google-ranking-factors don’t have much
relationship with Accessibility.
You can also read: SEO OVERLAP
While it’s important to understand where SEO and accessibility (a11y)
overlap in order to optimize correctly for both, it’s also important
to note that optimizing for one is not necessarily akin to optimizing
for the other. In other words, if you’ve optimized a page for search
engines, it doesn’t mean you’ve necessarily made it accessible — and
vice versa.
I keep seeing role attributes in some people's work. I use it too, but I'm not sure about its effect.
For example:
<header id="header" role="banner">
Header stuff in here
</header>
Or:
<section id="facebook" role="contentinfo">
Facebook stuff in here
</section>
Or:
<section id="main" role="main">
Main content stuff in here
</section>
Is this role attribute necessary?
Is this attribute better for semantics?
Does it improve SEO?
A list of roles can be found here, but I see some people make up their own. Is that allowed or a correct use of the role attribute?
Any thoughts on this?
Most of the roles you see were defined as part of ARIA 1.0, and then later incorporated into HTML via supporting specs like HTML-AAM. Some of the new HTML5 elements (dialog, main, etc.) are even based on the original ARIA roles.
http://www.w3.org/TR/wai-aria/
While the First Rule of Aria states:
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
there are a few primary reasons to use roles in addition to your native semantic element.
Reason #1. Overriding the role where no host language element is appropriate or, for various reasons, a less semantically appropriate element was used.
In this example, a link was used, even though the resulting functionality is more button-like than a navigation link.
Delete
<!-- Note: href="#" is just a shorthand here, not a recommended technique. Use progressive enhancement when possible. -->
Screen readers users will hear this as a button (as opposed to a link), and you can use a CSS attribute selector to avoid class-itis and div-itis.
[role="button"] {
/* style these as buttons w/o relying on a .button class */
}
[Update 7 years later: removed the * selector to make some commenters happy, since the old browser quirk that required universal selector on attribute selectors is unnecessary in 2020.]
Reason #2. Backing up a native element's role, to support browsers that implemented the ARIA role but haven't yet implemented the native element's role.
For example, the "main" role has been supported in browsers for many years, but it's a relatively recent addition to HTML5, so many browsers don't yet support the semantic for <main>.
<main role="main">…</main>
This is technically redundant, but helps some users and doesn't harm any. In a few years, this technique will likely become unnecessary for main.
Reason #3.
Update 7 years later (2020): As at least one commenter pointed out, this is now very useful for custom elements, and some spec work is underway to define the default accessibility role of a web component. Even if/once that API is standardized, there may be need to override the default role of a component.
Note/Reply
You also wrote:
I see some people make up their own. Is that allowed or a correct use of the role attribute?
That's an allowed use of the attribute unless a real role is not included. Browsers will apply the first recognized role in the token list.
<span role="foo link note bar">...</a>
Out of the list, only link and note are valid roles, and so the link role will be applied in the platform accessibility API because it comes first. If you use custom roles, make sure they don't conflict with any defined role in ARIA or the host language you're using (HTML, SVG, MathML, etc.)
As I understand it, roles were initially defined by XHTML but were deprecated. However, they are now defined by HTML 5, see here: https://www.w3.org/WAI/PF/aria/roles#abstract_roles_header
The purpose of the role attribute is to identify to parsing software the exact function of an element (and its children) as part of a web application. This is mostly as an accessibility thing for screen readers, but I can also see it as being useful for embedded browsers and screen scrapers. In order to be useful to the unusual HTML client, the attribute needs to be set to one of the roles from the spec I linked. If you make up your own, this 'future' functionality can't work - a comment would be better.
Practicalities here: http://www.accessibleculture.org/articles/2011/04/html5-aria-2011/
Is this role attribute necessary?
Answer: Yes.
The role attribute is necessary to support Accessible Rich Internet Applications (WAI-ARIA) to define roles in XML-based languages, when the languages do not define their own role attribute.
Although this is the reason the role attribute is published by the Protocols and Formats Working Group, the attribute has more general use cases as well.
It provides you:
Accessibility
Device adaptation
Server-side processing
Complex data description,...etc.
I realise this is an old question, but another possible consideration depending on your exact requirements is that validating on https://validator.w3.org/ generates warnings as follows:
Warning: The form role is unnecessary for element form.
The role and other attributes improve the accessibility for screen readers. It can indirectly help search spiders identify and understand the individual section better. If I compare this and microdata schema, it improves SEO in a small way.
Role attribute mainly improve accessibility for people using screen readers.
For several cases we use it such as accessibility, device adaptation,server-side processing, and complex data description.
Know more click: https://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute.
"role attributes" are developed to help people who have vision or eyesight issue. Screen readers inform the user about the elements. Even though this seems an easy task but it is not. if you are not expert and not sure, do not assign a role. you can read from here
It is important to understand that sometimes poor ARIA implementation
can cause more problems than it can solve, making the content less
accessible. This can happen because of a lack of knowledge of how and
when to use ARIA.
Some HTML elements have implicit roles. For example:
h1,h2...h6 -> heading
ul,li -> list
button -> button
a -> link
<input type="text"/> -> text
You can override those, to be more descriptive
In the case of SEO, You can read the-accessibility-and-seo-myth/
A Google search for “Search engine ranking factors” displays a number
of results featuring leaders in the SEO/ SEM industry that outline the
many factors that improve SEO. The vast majority of the identified
ranking factors have no relationship of any kind with Accessibility.
In fact, even many of the google-ranking-factors don’t have much
relationship with Accessibility.
You can also read: SEO OVERLAP
While it’s important to understand where SEO and accessibility (a11y)
overlap in order to optimize correctly for both, it’s also important
to note that optimizing for one is not necessarily akin to optimizing
for the other. In other words, if you’ve optimized a page for search
engines, it doesn’t mean you’ve necessarily made it accessible — and
vice versa.