So I'm themeing a custom captcha, and I want to of course adhere to the requirements, which are
While theming does give you many options, you need to follow some user interface consistency rules:
You must state that you are using reCAPTCHA near the CAPTCHA widget.
You must provide a visible button that calls the reload function.
You must provide a way for visually impaired users to access an audio CAPTCHA.
You must provide alt text for any images that you use as buttons in the reCAPTCHA widget.
src: https://developers.google.com/recaptcha/docs/customization
The first three aren't that hard, but the fourth is a bit tricky - I'm not using actual images, however I am using fontello glyphs. I understand that the alt text is in case the image doesn't load, but is it also what's read via text to speech applications for the visually impaired? If so, would it be a good idea to set the alt text on these glyphs as well?
Thank you,
Sidney
Related
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 working on doing accessibility remediation to several websites based off WCAG 2.0 AA standards. These sites have quite a lot of links to PDFs. Here is a common example of what they have:
Get Blah Information
Based on my best understanding of WCAG 2.0 AA principles, this links should have title text added, becoming something like:
Get Blah Information
My question is about this title text. It only seems occasionally appropriate. Most browsers will open the target="_blank" in a new tab, not a new window. Also, on mobile many devices will launch a native app to open the PDF. Some devices/browsers will actually download the file, depending on the settings. With all these considerations, is there a better, more universal title for these types of files?
It's generally considered courteous to give people a heads-up that that what they are clicking on will not open up as a webpage.
In my organization, we require that PDF links (or any link pointing to a non-HTML document) needs to clearly annotate the file type in the anchor text.
Like this:
Get Blah Information (PDF)
The title attribute isn't consistently supported among screen-reader/browser combinations, so I wouldn't recommend depending on it to work.
Links to Non-HTML Resources
https://webaim.org/techniques/hypertext/hypertext_links#non_html
Users should generally be alerted to links that lead to non-HTML resources, such as PDF files, Word files, PowerPoint files, and so on. However, there is some debate as to whether the content author or the browser should be the one to alert the user. The trouble is that none of the browsers or screen readers currently alert the user at all, so the debate is more theoretical than practical.
If you're opposed to putting the filetype in the anchor text, you could always use the aria-label attribute to supplement the anchor text, or position the text off screen so that it's not visible to sighted users, although these solutions may be less accessible for users with limited-sight ability.
I would avoid using the title attribute in this case. There are several issues with its use, and it should be avoided in most cases. For example, screen reader software will often read the title attribute in addition to the text that is already in the link, thus reading redundant and potentially confusing text. The way that the title attribute is handled is inconsistent across assistive technology. Read more about when to use and not use the title attribute.
Additionally, I would avoid describing the action that will take place. As you described, different technology/devices handle the link in different ways, and the user can even choose how to interact with the link (open in a new tab, etc). Instead, focus on describing the purpose of the link. Your first example: Get Blah Information is much better than the second.
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.
Many webpages have options where you can change the font size or increase contrast. Those options are most of time designed for visually impaired people.
What technics do you use to ensure that those people actually find the options to increase accessibility?
According to the WCAG 2.0 spec, a high-contrast toggle must itself be high-contrast. I've done this simply by creating simple black-on-white button (that inverts when hovered of focussed, for effect) at the head of my page. I opted to use a font-awesome icon for the button content, so I was careful to include role="img" and aria-label="High Contrast Toggle" in the <i>. I was also careful to make the toggle keyboard-accessible by adding a tabindex
It's better to make all text high-contrast by default, but I opted for the toggle as a learning challenge and also because I did not want to change my page's colour scheme. Alternatives to toggles that are suggested by the spec are using skrims or text-shadow. (description, 3rd paragraph). This would have looked and worked better, but my testing tools (WAVE Chrome extension v. 1.0.1) didn't detect the change, so I decided to make a toggle.
If you provide such widgets, you have to make sure that your document is also accessible without using them. Otherwise (= your document is inaccessible with the default settings) some users can’t find/reach/use your widgets to change the settings.
If you can’t make your whole document accessible without using the widgets, you should at least make sure that the widgets can be reached and used. This would be similar to providing a link to an alternate version.
As far as I know, there is no standard way to mark up or annotate such accessibility-related widgets. If they are important, it can make sense to have them as one of the first elements of the document.
(And just in case it’s not clear: it’s rarely necessary to provide such widgets, e.g., for text resizing, at all; there are often many other ways/technologies to make sure that your document is accessible.)
I am making a web page that displays fragments of text from news sites (CNN, BBC, etc.) but I also want it to be read to people who can't see. How can I program the HTML page to read the text for them? Any ideas?
Thanks, Boda Cydo.
People who can't see will already be using either a screen reader (which will read the text to them), braille display or similar.
You just need to focus on making the text accessible and let their software handle "displaying" it to them.
The best way to make your website readable to people who cannot see is to use semantic HTML and follow standards. HTML readers can't magically infer your meaning if you don't. For example:
Use H1-H6 to designate the correct levels of titles in your site
Use P tags for body content
Use UL lists for navigation and A tags only for things that are really links
Use CSS for style - If an image is just used for style, put it in a background image instead
Only use tables for data that really is tabular.
If you have any content images, use IMG and provide ALT text
Use LABEL tags appropriately for forms
Use title attributes where appropriate
Most importantly - try turning off CSS in your browser. Does your web page still make sense to you? If so, you are probably on the right path.
No, you need to use Flash or a Java Applet to do this. There is nothing native in a browser for text-to-speech. Most people with these needs already have software that does this for them.
look to http://en.wikipedia.org/wiki/JAWS_%28screen_reader%29 . As far as i know it have integration with browsers
As Diodeus noted, if they have a need for text to speech then they will already have software to read for them. Just make the text available.
If you actually want to go through with implementing it yourself (though I wouldn't recommend it) then you can try to use the Google Translate API as described here. It looks like Google has taken down that text-to-speech site for now, but I assume (since it's Google after all) that they'll eventually release it. You may want to also look at the Android TTS library here.