The WCAG 2.0 requirements and techniques regarding CAPTCHA include:
WCAG requirements 1.1.1 Non-text Content: CAPTCHA
CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
G143: Providing a text alternative that describes the purpose of the CAPTCHA
G144: Ensuring that the Web Page contains another CAPTCHA serving the same purpose using a different modality
I evaluate the Google reCAPTCHA v2 with these two demo:
https://www.google.com/recaptcha/api2/demo
https://recaptcha-demo.appspot.com/
It seems that reCAPTCHA v2 has the provided the describe text (in aria-live="polite" div), and the alternative accessibility solution for screen readers, which can fulfil the above requirement.
And I learned from this answer that automated accessibility tools, e.g. the WAVE tool, may return specific false positive. Beyond that the reCAPTCHA seems fine on my scans.
So, are there any violations? Can we say reCAPTCHA v2 is currently conforming to WCAG 2.0 AA?
Conforming to WCAG
Yes, but only because WCAG has added exceptions for the inherent accessibility problems with CAPTCHA. Conformance is not the same as actually working for people with disabilities
It fails at the first hurdle as I can't find a text alternative which is an A level requirement and the first WCAG rule.
Now while that rule does provide for CAPTCHA (so you get a technical pass) it certainly does not fit the spirit of this rule and has always been a point of contention on WCAG.
Providing an audio alternative doesn't work as some people are deaf and blind, which is why a text alternative is a must (a programatically determinable description etc.)
Usable / a good experience / accessible, absolutely not!
If you have poor vision there is no way you can differentiate the images.
If you have a cognitive disability you may not be able to associate the images correctly with the question being asked.
Using it with a screen reader (as a blind user) is horrendous as you have to use the audio captcha.
The audio captcha is useless if you also have a hearing impairment (it is hard to use even if you don't).
Using it with a braille screen (if you are blind and deaf for example) is impossible.
I could go on, but you get the idea. Especially that last point. Yes Google provides alternatives to "tick the boxes" but neither option is useful for someone who is blind and deaf.
Is it effective at blocking spam?
Not really, you can buy 1,000 captcha solves for $5!.
All you are actually doing is helping Google perfect self driving cars image recognition when you implement a Captcha (why do you think they show you pictures of buses) and annoy your visitors.
In the mean time you are
introducing friction for users who want to fill out your form (and depending on usage could result in a lower conversion rate),
making the site hard or impossible to use for disabled users
probably making your site slower (depending on implementation) as the Captcha library is bloated, hurting your Core Web Vitals.
Avoid and do not use!
Related
I was checking existing media-query parameters on MDN (link)
I saw prefers-reduced-transparency parameter:
The user prefers reduced transparency (Added in Media Queries Level 5)
I see the point for prefered themes (dark/light) or reduced animations, but I don't understand the need behind this rule.
I can't find any W3C exchanges that would explain why they added this to MQ5.
Does someone has infos on this please ?
Many groups of people may find it easier to understand text (and UI controls), or focus on activities, if they are presented with a plain, opaque background.
As Cody says in their answer, it can increase readability for users with visual impairments. For example:
A person with astigmatism may find it easier to read text on a plain background. (I do, and I frequently misplace my spectacles.)
It also benefits users with various cognitive impairments too. Background images, textures, gradients, or other patterns can:
Make shape recognition more difficult, e.g. for people with dyslexia or visual-spatial processing impairments.
Appear too "loud" or intense for people with autism-spectrum cognitive impairments.
Appear too "busy" for people with distractability or working-memory impairments.
Increase the cognitive effort required when a user is tired, or is experiencing a headache.
(I'm not an expert on cognitive impairments, so this simplistic overview is the best I can give just now. There are many more types and degrees of cognitive impairments.)
Note that prefers-reduced-transparency and prefers-contrast are separate concerns. The CSS-WG tracking issue for this (Media Feature: "increase contrast" and/or "reduce transparency" user settings) has a useful comment:
Low vision disabilities are too diverse to make sweeping generalizations like, "People who what higher contrast text also want zero transparency"
In this issue at csswg-drafts, there's a reference to a discussion thread that has the following clue:
prefers-reduced-transparency
Allows certain translucent views to switch to an opaque rendering.
(…) This increases readability for certain individuals with vision impairments.
So the underlying need for this rule would be aiding vision impairment among users. I also would like to see some more documentation on this feature.
How can I ensure (or try to make) web access available for all - who may have a variety of disabiltes?
Any advice for any standards or web sites that could give me some pragmatic advice for the design of a site?
There are a number of considerations you need to address here, if your website isn't catering for a specific disability then you have to work on a broad range of features. In this situation the first thing you need to remember is that you sadly can't cater to everyone. Look at the list below and identify which of these disabilities you can sensibly cater for
Visual: Visual impairments including blindness, various common types
of low vision and poor eyesight, various types of color blindness;
Motor/Mobility: e.g. difficulty or inability to use the hands,
including tremors, muscle slowness, loss of fine muscle control, etc.,
due to conditions such as Parkinson's Disease, muscular dystrophy,
cerebral palsy, stroke;
Auditory: Deafness or hearing impairments,
including individuals who are hard of hearing;
Seizures: Photoepileptic seizures caused by visual strobe or flashing effects.
Cognitive/Intellectual: Developmental disabilities, learning
disabilities (dyslexia, dyscalculia, etc.), and cognitive disabilities
of various origins, affecting memory, attention, developmental
"maturity," problem-solving and logic skills, etc.
The easiest here is the Seizures, eliminate flashing / strobing content from your site, or more importantly if you cant put up a warning before displaying this type of content.
Users with Motor / Mobility issues may have problems interacting with content on your site that requires a high amount of precision, this can be helped by increasing the size of your UI elements, or allowing the user to resize these elements if needed.
Generally make anything clickable as large as is feasible and if you have elements that have features such as drag drop, make the drag handles large so the user doesn't have to click a tiny area.
Auditory is also a fairly easy consideration to make, at the least simply provide text alternatives to any media content your site may have, for larger sites using video then considerations such as sign language may be an option.
Visual is probably the most common consideration web developers need to make. Firstly partially sighted users may want to increase the text size to your page, so make sure that your UI can cope with this. Use clear and readable fonts and make sure there is contrast between the background color and the font color.
Color blind users may wish to change your site color scheme to meet their needs, you can find information easily on the types of color blindness and develop a couple of alternative CSS styles to meet these needs. Also a high contrast option for everything on your site may benefit partially sighted users.
Cognitive / Intellectual is one of the harder considerations to meet, so look at the individual disabilities. ADD for instance makes it hard for a person to focus and makes them easily distracted, considering this think about advertisements, they are designed to distract us and draw our attention, thus by limiting advertisements on your site you can get rid of the ones that flash and scream Click ME!.
Dyslexic users may struggle with reading huge chunks of text which also fits in with considerations for partially sighted people, here you could have an audio option so the text is read aloud to the user.
One more consideration here is the use of color in your website. It has been proven that certain colors can stimulate emotions, for someone with emotional or developmental issues using colors that are considered calming vs ones that excite (reds for example) may improve their experience of your website.
All of the above are design considerations, looking at the development (Code) next there isn't too much you can do, most of the considerations about your code are because of third party applications interacting with your site.
Generally make sure your code is well formed, correct tags / closing tags etc. Make sure it is valid HTML / XHTML / CSS etc if you can validate to the strict standards it wont hurt your cause. Tags such as links / images should have appropriate Alt text to describe what the element is, for instance alt="image1" is fairly useless to a screen reader but alt="Image showing ...... clicking this will take you to....." is useful.
If you can find some trial software grab yourself a screen reader, load up your website, close your eyes and try interact with it, its going to be hard but at least you can see how your user will interact with your site and more importantly you can use the screen reader to check your site actually gets read the way it should.
There are plenty of 3rd party plugins you can integrate with your site to aid your users too, so look into those, things like the option to magnify text or read aloud with just a click will be well received as long as they are not too intrusive to your non disabled users.
Helpful links
http://www.w3.org/TR/WCAG10/ The W3C Disability guidelines are a good place to start
http://en.wikipedia.org/wiki/Web_accessibility Wikipedia web accessability
http://www.etre.com/tools/colourblindsimulator/ Allows you to see how images will appear to colourblind users
http://colorfilter.wickline.org/
http://www.w3.org/WAI/ W3C Web Accessability Initiative Guidelines
Section 508 is the section of the law that requires that US government websites be accessible.
More information is here, including best practices on making content accessible to all.
http://www.section508.gov/
Generally you should support screen readers by using semantic markup, and avoid flashy content and audio -- these are usually impossible or just difficult to make accessible.
You should also look at web typography guidelines and look to hiring a good designer. Poor color schemes, typefaces, and font sizes make reading on the web much harder than it needs to be.
If you're from the UK, from a legal POV you want to be looking at the Equality Act (which replaced the Disability Discrimination Act).
The foundation of web accessibility is based on the graceful degradation/progessive enhancement model (sounds more complicated than it is!). A List Apart wrote a great article on it some time ago.
A good starting point for web professionals is the RNIB's Web Access Centre. Obviously this mainly deals with those user who experience visual disability, but it's a very useful resource.
Web AIM is also a good site for resources/articles although I'm not sure how often it's maintained these days (still, the information there is relevant).
There are far too many individual little things to bear in mind when developing accessible interfaces, but if you take the time to read some of the articles on those sites, you'll pick up the fundamentals which will then lead you onto the more nitty-gritty things.
Accessible development is about a change in mindset as much as learning the nuts and bolts. You need to to be constantly asking yourself "How might other people use this? What barriers might be in their way? What browser are they using? Does this work without colour/JavaScript/CSS?". Learn how to take your site apart and see if it still works.
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the W3C Recommendation from Web Accessibility Initiative (W3C/WAI).
An overview can be found here: http://www.w3.org/WAI/intro/wcag20
There are very broad Principles as well as precise Techniques (for HTML, CSS, JS, Flash, etc) and the intent of each and every criteria. These aren't documents meant to be read at once and you'll want to learn more from tutorials and articles found on the web (archives at 456 Berea Street, WebAIM, videos about accessibility)
The W3C Quick Reference guide to WCAG 2 lists all of the relevant techniques you'll need to implement the WCAG2 principles and guidelines that Felipe mentioned, with code examples if appropriate on the individual technique pages. If it's all a bit too technical for you, WebAIM's checklist is the same thing only in plain English.
Unfortunately there's no magic wand for getting sites to be compliant. You have to go through each bit of content and test it and modify it if necessary. Luckily, even some small improvements can make a big difference.
A lot of good answers, but I can't help adding my input as well.
If you want to ensure a website is disabled friendly, there are a number of considerations that should be taken. One that I have not seen on here (perhaps because I skimmed) is to ensure that you use high-contrast colors, with a solid background behind text.
However, you should NOT use white on black or white on black...dyslexics commonly cannot see those colors. Use an off-white for background or text.
Also, make sure your text is large. Ensure as much of the content as possible is standard text, so that text-to-speech programs can "read" the website. Text-to-speech cannot read images. Text links instead of buttons would also be advisable, for the same reasons (though there may be a means of associating text with a button for these scenarios...?)
for some niche reasons I often find that a text-only captcha would be better than the traditional image/audio solutions. Some of the reasons I can think of off the top of my head:
Text-based browser support(lynx, links, etc)
To provide write-capable public APIs, but prevent massive amount of spam
For accessibility reasons (I've heard that the audio versions are very hard to understand to prevent voice-recognition software attacks)
Are there any text-only CAPTCHA systems available out there?
http://textcaptcha.com/ is a logic based, but also purely text based, captcha system., and is free too.
I don't think you have any control over the type of questions that are passed to you, but worth reading the documentation. Whilst it may pose problems for users with cognitive disabilities, it's on the right track, and an improvement on the standard recaptcha type captchas, which create difficulties for blind and vision impaired users alike.
All of the CAPTCHAs I've seen that don't use images or audio involve some sort of cognition:
What day of the week is tomorrow?
Who was the host of last week's SNL?
What is 2 + 3 plus four?
I've never really learned much about accessibility but it seems like an important topic.
When you build a website or piece of software, or when you're talking to a client about a website, where does accessibility come in? Or from your experience, if you don't have accessibility in something you've built for a client, do you get a lot of requests to include it, or does it limit you in some financial way?
What are the numbers, I guess. What's the return in your business, how many people have you talked to that need it? Do you yourself need accessibility features?
I do mainly Flex/Flash and it seems like I'll have to do a bit of work to have full accessibility.
Thanks for the help.
As a person with a disability myself, I am consious of adding accessibility features when I write software
Accessibility is an area of software design concerned with making software user interfaces avvessibile for people with physical or mental disabilities or imparements. Different people have different specific needs and you can't be expected to cater specifically to each but there are some broad groupings
Visual Imparements:
This includes blindness or color blindness. To assist in this area consider providing "good" alt text (clarified blow) and hints so that screen readers can present a view of your content that makes sense aurally. Providing easy access to links to raise text size and/or access to some high contrast stylesheet options is also a good idea.
Non-Mouse Users
There are a huge number of conditions that can prevent one from being able to successfully mouse, it took a few years for me and my brain, which is somewhat unreliable when it comes to spatial relationships to pick up the skill. For these people keyboard access is really helpful, I don't work in the web space so I'm not sure if there are standard keys to use, but these are communicated by screenreaders and tooltips so having any is better than none.
Hanselminutes episode #125 is quite educational. He talks with a blind user about accessibility on the web and in generalAccessibility is omitted from a lot of design processes, either because businesses don't have an immediate need for it and therefore don't consider it at all, or consider it a low priority feature. Leguslation in various countries has helped a bit in this regard, but the real problem is that accessibility in general is usually an afterthaught to the design process,
1"Good" alt text is judicious use of alt text that accentuates the content or purpose of a page, navigation elements should have alt text describing where interacting with them will take the user, similarly, things that aren't content, like spacers should have no alt text at all, because there is nothinng worse then hearing "Foo's widgets spacer spacer spacer spacer spacer nav_Products spacer nav_support"
I think accessibility is usually completely forgotten about (either implicitly or explicitly dismissed beforehand because of issues like cost) in most software development projects. Unless companies (or individual developers, more likely) already have experience with either people with disabilities or with writing software with disabilities of users in mind.
As a developer I at least try to do keyboard shortcuts correctly in software I work on (because that's something I can easily dog-food myself, since I try to keep hands-on-keyboard as much as possible). Apart from that it depends on whether there are requirements about accessibility.
I do think this kind of thing is part of "programming taxes", i.e. things that you as a developer should always be doing, but...
I am only aware of this - at least more than the average developer, I think - because I have once written software for a software magazine on floppy disk, or Flagazine. This was in PowerBasic 3.2, grown out of BASIC sources in a magazine, making these sources available by BBS and disk, eventually growing a menu around the little applications to easily start them, etc.
One of our primary users (and later members of the editorial staff) was blind and was appalled when we switched from text mode to an EGA mouse driven menu, as his TSR screenreader software couldn't do anything with graphics. It turned out that his speech synthesizer simply accepted text from a COM port. It had a small (8K I think?) buffer that would be instantly cleared on reception of (I think) an ASCII 1 character. And that was it.
So we made the graphical menu (and most other programs on the Flagazine) completely keyboard accessable at all times and in the graphical programs we use a small library I wrote to send ASCII text to a configured COM port. This had small utility methods like ClearBuffer(). With this, and the convention of speaking possible menu actions when pressing the space bar, made all of this software accessable to our blind users.
I even adapted a terminal application for my HP48 calculator (adding a clear buffer/screen on ASCII 1) so I could use that to emulate a speech synthesizer. I would then test all of our software in each Flagazine by attaching my HP48 with the emulator running, turning off my computer monitor and trying if I could use all the software without seeing anything.
Those were the days, about 12 years ago... ;-)
I am a blind individual so have to develop with accessibility in mind if I want to use my own programs. I find my self focusing on accessibility based on the type of application I’m writing. When doing command line or mainframe applications I don’t think about accessibility since those environments are inherently accessible. With web based applications I have to give some thought to accessibility but not a lot. This is mainly because I write simple web applications for limited use so don’t have to worry about making the interface appealing, just usable. The area I spend the most time focused on accessibility is desktop applications. For example using .net I need to make sure accessible properties are set properly and that labels are in the proper position in relation to a text box so my screen reader can find them and associate them with the proper control.
I understand that some countries have laws regarding website accessibility. In general, what are the minimum requirements that a website must meet to be accessible, regardless of country? Or, in lieu of minimum requirements, what are some specific things that websites should have to make the accessible?
W3C publishes Web Content Accessibility Guidelines:
http://www.w3.org/TR/WAI-WEBCONTENT/
If you want a quick summary list, look for the yellow-highlighted lines in that document. Each guideline is also broken down into specific requirements ("checkpoints") in one of three priorities - to claim any kind of accessibility under this scheme you must satisfy all priority 1 checkpoints, but they're "necessary" rather than "sufficient" conditions.
Looking at your pages in lynx is also a good measure - if it won't render in text, chances are good that a screen reader will have a difficult time of it too.
I recommend A-prompt for testing of Accessibility.
It is free and it can really help.
I also recommend Mark Pilgrim's online text - Dive into Accessibility.
It's not a binary question, and there's no silver bullet. Making sure you follow at least the basics of WCAG and testing in a couple of screen readers and without the mouse will probably be the most effective use of your time. If at all possible, test with real people with real disabilities, they have a perspective that is hard for fully-abled people to attain.
Well, obviously the law in different countries varies vastly. In the UK, for example, we don't have any specific web-accessibility laws, but no service is allowed to discriminate against someone with a sight or hearing impediment, insofar as it relates to functionality.
In light of this, a simplistic way to design would be to ensure that your website is readable by screen-readers, can be tabbed through successfully and in a logical order, and allows the scaling of screen elements (including images and font sizes) correctly for those who require web-pages to be magnified.
In addition, your website should have functionality fall-backs in place for any JavaScript and Flash, such that if they were turned off (such as is the case in many screen readers) all functionality is still usable. Don't rely on WAI-ARIA for JavaScript accessibility, as it isn't standardised, and it isn't widely supported.
Of course, this doesn't necessarily cover every possible law, but it's a good starting point. If your website meets the above 'criteria', you're likely to have a good level of accessibility. There is a test for accessibility, of sorts, following WCAG but it's by no means 'conclusive' for what is an acceptable level of accessibility in each individual country.