Ask HN: Best way to test accessibility of a website?
115 comments
Pay me to do it...
But in all seriousness, I use aXe-Coconut[1], headingsMaper[2]. Then tab through the page and make sure you can get from top left to bottom right. The cursor[focus state /ouline] should be visible the whole time and you should never lose your place.
When you are done that, if you have a Mac turn on voiceover with Command+F5 and use Safari or Chrome (more aria-support). On Windows, download NVDA[3] and FireFox. Again use the keyboard to go through the page, but listen to the screen reader and make sure everything is spoken like it looks. So a button should say, "Submit Form Button" etc. Anything that doesn't say anything, ie, " button" or say something different from what you see needs work.
The general consense of the community is that automated testing only finds 30% of issues, so you've got to test manually.
[1] https://chrome.google.com/webstore/detail/axe-coconut/iobddm... [2] https://chrome.google.com/webstore/detail/headingsmap/flbjom... [3] https://www.nvaccess.org/
But in all seriousness, I use aXe-Coconut[1], headingsMaper[2]. Then tab through the page and make sure you can get from top left to bottom right. The cursor[focus state /ouline] should be visible the whole time and you should never lose your place.
When you are done that, if you have a Mac turn on voiceover with Command+F5 and use Safari or Chrome (more aria-support). On Windows, download NVDA[3] and FireFox. Again use the keyboard to go through the page, but listen to the screen reader and make sure everything is spoken like it looks. So a button should say, "Submit Form Button" etc. Anything that doesn't say anything, ie, " button" or say something different from what you see needs work.
The general consense of the community is that automated testing only finds 30% of issues, so you've got to test manually.
[1] https://chrome.google.com/webstore/detail/axe-coconut/iobddm... [2] https://chrome.google.com/webstore/detail/headingsmap/flbjom... [3] https://www.nvaccess.org/
Check the WCAG success criteria that your jurisdiction requires. One less obvious, and commonly required, criteria (WCAG 2.4.1[1]) is that the site has some mechanism by which a screen reader user can jump from the beginning of the document to the main content, without having to browse through the preceding navigational links and similar.
[1] https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechan...
[1] https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechan...
Skip-links should also be accessible for keyboard users.
Good point, I'm not a fan of FaceBook but they do an amazing job of this.
If you tab out of the URL bar of your browser, Facebook has a huge accessibility skip links menu.
If you tab out of the URL bar of your browser, Facebook has a huge accessibility skip links menu.
I would add, to really test, after turning on voice over, turn off your monitor. This will let you test if you can explore your website with the visual structure.
Don't do this - the best way to evaluate is to compare the visual output with the auditory output, something you can't do if the screen is turned off.
The two practices are not mutually exclusive. Why not test against both?
I sort of agree, from my experience, I know what to expect when I see something, so seeing and hearing helps me quickly spot the issue.
what are your rates and why are you qualified?
I don't want the extra work. But I do accessibility as my full-time job.
Do you have a recomended service? Part of our service has us hosting a form for our customers that is exposed to their users, so accessibility is a priority.
Thanks for any pointers!
Thanks for any pointers!
I've worked with people from Level Access[1] and Deque[2], there is also TPG[3]. I'm not sure how much money they cost, but they are the real experts in the industry. Some people on Fivver offer services, but I don't know how qualified they are.
[1] https://www.levelaccess.com/ [2] https://www.deque.com/ [3] https://www.paciellogroup.com/
[1] https://www.levelaccess.com/ [2] https://www.deque.com/ [3] https://www.paciellogroup.com/
Thank you.
+1 for this advice. Identifying the issues is just one part of the work, finding a correct and usable solution might be lots of work if you don't have much experience with accessibility.
I also do full-time accessibility work. Don't need extra work right now, but feel free to get in touch to discuss work in the (near) future.
I also do full-time accessibility work. Don't need extra work right now, but feel free to get in touch to discuss work in the (near) future.
Finding a solution is the hard part. I've found, the few times that I've been able to sit with the developer and test their code as they tried to solve an accessibility problem was the best method.
What about JAWS and IE on Windows? Most disability groups distribute and use JAWS not NVDA. (Assuming OP is in the United States)
JAWS costs around $1000, NVDA is free. I'm assuming the person doesn't have the budget to buy JAWS. There is a demo for JAWS, but its 40 minutes, that isn't going to be enough to test a page (especially when you need to restart your computer for another 40 minutes).
Microsoft recently open sourced[1] one of the main tools they use for web accessibility testing.
Accessibility Insights for Web (https://accessibilityinsights.io) is a Chrome extension that guides you through doing an accessibility assessment of a website. It includes a combination of automated checks (using aXe[2]) and assisted/guided manual checks. Its rules are based on the W3C Web Content Accessibility Guidelines[3]; passing a full assessment in the tool amounts to meeting all the "A" and "AA" WCAG 2.0 requirements.
Like other commenters have mentioned, automated checks (like aXe) are a great start, but aren't really sufficient on their own. Accessibility Insights will lead you through how to test different aspects of screen reader usage (and other types of accessibility issues, too!). It will also help you track issues as you go, and produce a pretty report at the end that you can attach to a bug.
As with most types of UI testing, no matter what tools you're using, there's really no substitute for watching a real user try to use your product.
Disclaimer: I am an engineer that works for Microsoft on the Accessibilty Insights team.
[1] https://cloudblogs.microsoft.com/opensource/2019/03/12/micro... [2] https://www.deque.com/axe/ [3] https://www.w3.org/WAI/WCAG21/quickref/
Accessibility Insights for Web (https://accessibilityinsights.io) is a Chrome extension that guides you through doing an accessibility assessment of a website. It includes a combination of automated checks (using aXe[2]) and assisted/guided manual checks. Its rules are based on the W3C Web Content Accessibility Guidelines[3]; passing a full assessment in the tool amounts to meeting all the "A" and "AA" WCAG 2.0 requirements.
Like other commenters have mentioned, automated checks (like aXe) are a great start, but aren't really sufficient on their own. Accessibility Insights will lead you through how to test different aspects of screen reader usage (and other types of accessibility issues, too!). It will also help you track issues as you go, and produce a pretty report at the end that you can attach to a bug.
As with most types of UI testing, no matter what tools you're using, there's really no substitute for watching a real user try to use your product.
Disclaimer: I am an engineer that works for Microsoft on the Accessibilty Insights team.
[1] https://cloudblogs.microsoft.com/opensource/2019/03/12/micro... [2] https://www.deque.com/axe/ [3] https://www.w3.org/WAI/WCAG21/quickref/
Hey I just tried this out, it's pretty awesome. Hadn't heard of it at all before. Love the tab-index mapping. Have you folks talked to the Lighthouse team to get your work integrated there; or at least possibly referenced there? I know lighthouse has a couple of accessibility recommendations, would be nice to have visibility on it.
- Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website.
- Disable JavaScript and use your website. This may not be relevant for web apps, but regular websites should work normally.
- Try to use your website with only the keyboard.
- Try to use your website with extreme zoom levels and font size overrides.
- Monitor your resource sizes. Anyone with a limited connection (a LOT of people) will abandon your website because it loads slowly, or are paying actual money for the wasted bandwidth.
I'm not aware of automated methods that give better results than using your website with the actual accessibility tools yourself.
- Disable JavaScript and use your website. This may not be relevant for web apps, but regular websites should work normally.
- Try to use your website with only the keyboard.
- Try to use your website with extreme zoom levels and font size overrides.
- Monitor your resource sizes. Anyone with a limited connection (a LOT of people) will abandon your website because it loads slowly, or are paying actual money for the wasted bandwidth.
I'm not aware of automated methods that give better results than using your website with the actual accessibility tools yourself.
I'm lucky enough to have a low-vision person who works as a tester on my team, and does our accessibility testing. It's very impressive watching/listening to him use a screen reader - I was really amazed at how fast he has it set to read the screen.
He does suggest all the things you've mentioned above, and it's good advice.
However one thing he also says is: don't assume that low-vision is the only type of disability. You also need to build software for people who are: deaf, have slow motor skills (e.g. avoid putting strict time limits on user actions, or making things jump around on the screen too much while people are trying to hit a target), lack fine motor skills (e.g. don't make a target too small), etc.
He does suggest all the things you've mentioned above, and it's good advice.
However one thing he also says is: don't assume that low-vision is the only type of disability. You also need to build software for people who are: deaf, have slow motor skills (e.g. avoid putting strict time limits on user actions, or making things jump around on the screen too much while people are trying to hit a target), lack fine motor skills (e.g. don't make a target too small), etc.
> However one thing he also says is: don't assume that low-vision is the only type of disability. You also need to build software for people who are: deaf, have slow motor skills (e.g. avoid putting strict time limits on user actions, or making things jump around on the screen too much while people are trying to hit a target), lack fine motor skills (e.g. don't make a target too small), etc.
These are also good UX guidelines in general.
These are also good UX guidelines in general.
I had the same reaction when watching blind YouTubers show how they use VoiceOver. It was so fast I couldn't understand or follow along.
A good takeaway was feeling their frustration with improperly labeled items. You want to order keywords first, for instance "March 25, created on" instead of "Created on March 25", because they have to wait through "Created on:" dozens of times, when they already know the label context.
Good points on the other accessibility areas.
A good takeaway was feeling their frustration with improperly labeled items. You want to order keywords first, for instance "March 25, created on" instead of "Created on March 25", because they have to wait through "Created on:" dozens of times, when they already know the label context.
Good points on the other accessibility areas.
Interesting that the en-GB pattern of naming dates ("25 March", not "March 25") would make it that much more efficient, but I imagine that's culturally unacceptable to the average US citizen?
> "Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website."
I doubt this is going to be very effective. Sure, it's better than nothing at all, but this is akin to sighted person with zero blindness experience testing the effectiveness of a newly designed white cane, only a website is much more complicated.
You should always find someone with personal experience to test it themselves and provide feedback if you want a clear understanding of how it will actually work for that community.
I doubt this is going to be very effective. Sure, it's better than nothing at all, but this is akin to sighted person with zero blindness experience testing the effectiveness of a newly designed white cane, only a website is much more complicated.
You should always find someone with personal experience to test it themselves and provide feedback if you want a clear understanding of how it will actually work for that community.
Even if someone with personal experience is better I would still highly recommend testing these tools as it's not always clear how they work if you haven never used them.
I was really surprised the first time I tested one of these tools and now I know a few dos and don'ts when developing web apps.
I was really surprised the first time I tested one of these tools and now I know a few dos and don'ts when developing web apps.
The metaphor is slightly off-the-mark. Testing a fancy new white cane would be like testing the accessibility tool itself. If you are developing that, then you definitely need an expert in such tools (probably a blind person).
However, developing the site is more akin to developing... a hallway? You can test whether blind people can navigate your hallway by closing your eyes and walking down it whilst using a cane. This is a bit easier- you just need to make sure there aren't obvious pitfalls and dangerous obstacles, maybe that there's braille on the doors etc.
Having an actual blind person helping you out in the second case is obviously preferable, but if you cannot, I think most blind people would appreciate you putting in the effort and at least trying to make it accessible, as opposed to the alternative of not caring at all. A lot of accessibility is standardized and there are guides to follow. It can sometimes be tricky, to be sure, but it's doable.
However, developing the site is more akin to developing... a hallway? You can test whether blind people can navigate your hallway by closing your eyes and walking down it whilst using a cane. This is a bit easier- you just need to make sure there aren't obvious pitfalls and dangerous obstacles, maybe that there's braille on the doors etc.
Having an actual blind person helping you out in the second case is obviously preferable, but if you cannot, I think most blind people would appreciate you putting in the effort and at least trying to make it accessible, as opposed to the alternative of not caring at all. A lot of accessibility is standardized and there are guides to follow. It can sometimes be tricky, to be sure, but it's doable.
>> Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website.
> I doubt this is going to be very effective.
You are wrong. The only way for a primarily sighted team to build accessible software is to test and iterate on accessibility as part of day-in, day-out development practices. Think of it the same as localization for RTL languages or cross-browser testing: you should test in each environment you support before merging a change. Training and user-testing with blind community are important, but it doesn’t take a native Arabic speaker to notice broken layout in Arabic, nor does it take an Android device owner to notice usability problems in Android Chrome.
The best front-end engineers I know all have a VoiceOver hotkey on their dev machines and phones, and I regularly see them testing sites they visit for keyboard navigation, focus management, and VoiceOver usability.
> I doubt this is going to be very effective.
You are wrong. The only way for a primarily sighted team to build accessible software is to test and iterate on accessibility as part of day-in, day-out development practices. Think of it the same as localization for RTL languages or cross-browser testing: you should test in each environment you support before merging a change. Training and user-testing with blind community are important, but it doesn’t take a native Arabic speaker to notice broken layout in Arabic, nor does it take an Android device owner to notice usability problems in Android Chrome.
The best front-end engineers I know all have a VoiceOver hotkey on their dev machines and phones, and I regularly see them testing sites they visit for keyboard navigation, focus management, and VoiceOver usability.
I agree that you should find someone who is blind to test your site for problems that a blind person will encounter, however I think you are wrong about a website being more complicated than a white cane - or rather it is not a white cane one tests, it is the accessibility of the world around you with that cane, and the world around you is more complicated to understand with a white cane than a website with voiceover turned on.
With voiceover it will very quickly let you know if you have something important for the user to get to that either takes too long to get to, or is not accessible at all. Voiceover is a useful tool at the development stage, after you have your near MVP then please get someone with personal experience to give it a full test.
With voiceover it will very quickly let you know if you have something important for the user to get to that either takes too long to get to, or is not accessible at all. Voiceover is a useful tool at the development stage, after you have your near MVP then please get someone with personal experience to give it a full test.
> - Disable JavaScript and use your website. This may not be relevant for web apps, but regular websites should work normally.
I'm not sure how this is related to accessibility? Are there tools for visually impaired people that don't work well with JS?
I'm not sure how this is related to accessibility? Are there tools for visually impaired people that don't work well with JS?
It's less critical now that browsers have standardized on the ARIA interface so it's more likely that JS sites will work, as long as you use ARIA correctly, but also note that many users are on older combinations — e.g. JAWS on IE11 is still fairly common — and you have no easy way to measure screen-reader activity so it's hard to tell whether, say, the 5% of your old IE traffic is a high percentage of your screen reader users.
The other challenge is that many JavaScript-heavy sites have horrible fallback mechanisms and you would want to test to make sure that at least someone with a screen reader would have an idea of why they're not hearing any content.
The other challenge is that many JavaScript-heavy sites have horrible fallback mechanisms and you would want to test to make sure that at least someone with a screen reader would have an idea of why they're not hearing any content.
Traditionally screen readers didn't. I'm not sure if that's still the case.
However, with no JavaScript (and modern css) you can't change the randomly after load to indicate state, which may be difficult for a screen readers to get that back to a blind person.
However, with no JavaScript (and modern css) you can't change the randomly after load to indicate state, which may be difficult for a screen readers to get that back to a blind person.
+ see if browser's readability function works (for long-read pages)
Does anyone else find this to be incredibly inconsistent between browsers? Edge is probably the best, surprisingly. Safari is the worst, it sometimes ignores entire sections of an article, regardless of using correct semantic markup.
I basically gave up on this, and just focus on using the appropriate semantic HTML tags, it's not my problem if a browser mangles it.
I basically gave up on this, and just focus on using the appropriate semantic HTML tags, it's not my problem if a browser mangles it.
That's a nice checklist. I'd like to add "Test with a console browser" too. If the site is usable in Links2/Lynx/w3m then it will most likely work for everyone.
Many sites break at moderate zoom levels.
In your test environment send HTML as type application/xhtml+xml, block all CSS and images, and add JavaScript that locks the mouse cursor to the first pixel on the screen. Then test the site for content and usability as you normally would.
Vision impaired persons do not benefit from CSS or images. All images should have proper corresponding alternate text. Changing the media type of the HTML does require a bit more strict syntax, but it also is a cheap trick to ensure the HTML tags and structure are arranged in a valid way.
I do not recommend disabling JavaScript. JavaScript is for interaction and blind persons need JavaScript just the same as the rest of us to navigate through content on complex sites. Inserting code that locks the mouse cursor to a single location forces QA to navigate the site/content using a keyboard.
Doing these things is the cheapest way to test for very basic compliance. In order to achieve AA WCAG 2.0 conformance you actually have to understand accessibility and classes of disabilities. You might be able to get some quick wins with tool automation, but manual testing is much better. There is one exception, color contrast. You absolutely need to use a tool to perform color contrast validation, because people eyes aren't good at accounting for both luminescence and contrast at the same time.
EDIT:
In FireFox (Windows) you can turn off CSS by clicking the ALT keyboard key to bring up the main menu then View -> Page Style -> No Style
Vision impaired persons do not benefit from CSS or images. All images should have proper corresponding alternate text. Changing the media type of the HTML does require a bit more strict syntax, but it also is a cheap trick to ensure the HTML tags and structure are arranged in a valid way.
I do not recommend disabling JavaScript. JavaScript is for interaction and blind persons need JavaScript just the same as the rest of us to navigate through content on complex sites. Inserting code that locks the mouse cursor to a single location forces QA to navigate the site/content using a keyboard.
Doing these things is the cheapest way to test for very basic compliance. In order to achieve AA WCAG 2.0 conformance you actually have to understand accessibility and classes of disabilities. You might be able to get some quick wins with tool automation, but manual testing is much better. There is one exception, color contrast. You absolutely need to use a tool to perform color contrast validation, because people eyes aren't good at accounting for both luminescence and contrast at the same time.
EDIT:
In FireFox (Windows) you can turn off CSS by clicking the ALT keyboard key to bring up the main menu then View -> Page Style -> No Style
> Vision impaired persons do not benefit from CSS or images
They might. You probably mean blind people.
They might. You probably mean blind people.
No, I mean vision impaired. There are all kinds of different vision disabilities besides blindness and color blindness.
Yes, exactly. And many such impairments will not prevent you benefitting from layout, colors, typography, images, and sundry other kinds of graphical trickery.
Sounds like you are confusing non-blindness for normal functionality. Fortunately, Wikipedia has a page for this: https://en.wikipedia.org/wiki/Visual_impairment
The idea of accessibility is that a product/service is available to a wide audience regardless of their physical/cognitive impairment. It is still discriminatory if some user might be capable of enjoying visual eye candy if they must struggle to do so due to an impairment and are denied access to that content otherwise.
The idea of accessibility is that a product/service is available to a wide audience regardless of their physical/cognitive impairment. It is still discriminatory if some user might be capable of enjoying visual eye candy if they must struggle to do so due to an impairment and are denied access to that content otherwise.
I don't think you are understanding the parent correctly. They are saying a person with a partial visual impairment can still benefit from a well-designed visual page layout, because a person with partial visual impairment might still use vision in some ways. So well-designed CSS and images DO benefit those individuals. You seem to be implying that anyone with a visual impairment, even a partial one, would prefer to browse with CSS and images off. But that's not necessarily the case.
What does that have to do with accessibility?
> You seem to be implying that anyone with a visual impairment, even a partial one
I am not. Well written CSS, a subset of usability, is irrelevant to accessibility.
> You seem to be implying that anyone with a visual impairment, even a partial one
I am not. Well written CSS, a subset of usability, is irrelevant to accessibility.
> Well written CSS, a subset of usability, is irrelevant to accessibility.
Says who?
https://www.w3.org/WAI/fundamentals/accessibility-usability-...
> There is a significant overlap between accessibility and usability. ISO 9241-11, defines usability as: The “extent to which a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfaction in a specified context of use”. This could address accessibility when: “specified users” includes people with a range of disabilities, and “specified context of use” includes accessibility considerations such as assistive technologies.
Let me give an example: If I put icons on my buttons to improve the usability of my app, but the icons break at high zoom levels, then is that accessible? No, but you'd never know unless you do accessibility testing with CSS and images turned on.
Says who?
https://www.w3.org/WAI/fundamentals/accessibility-usability-...
> There is a significant overlap between accessibility and usability. ISO 9241-11, defines usability as: The “extent to which a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfaction in a specified context of use”. This could address accessibility when: “specified users” includes people with a range of disabilities, and “specified context of use” includes accessibility considerations such as assistive technologies.
Let me give an example: If I put icons on my buttons to improve the usability of my app, but the icons break at high zoom levels, then is that accessible? No, but you'd never know unless you do accessibility testing with CSS and images turned on.
> but the icons break at high zoom levels, then is that accessible?
Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.
Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.
Bad usability precludes good accessibility. You seem to be implying that accessibility is just about being able to access the content. That's wrong, accessibility is about ease of access to the content. If what you were saying were true, then semantically correct HTML wouldn't be a WCAG requirement. But semantically correct HTML improves usability for people using assistive technologies, thus it is an important part of designing accessible content. Accessibility IS dependent on usability.
If just the ability to access the content was the only factor in designing accessible content, then you could just tell your blind clients to view the page source and read it character by character. But obviously that would not be acceptable because it creates a significant barrier for usability that sighted clients would not face. Designing accessible content is about removing barriers that make it harder for people with disabilities to access the content, and bad usability is one of those barriers.
If just the ability to access the content was the only factor in designing accessible content, then you could just tell your blind clients to view the page source and read it character by character. But obviously that would not be acceptable because it creates a significant barrier for usability that sighted clients would not face. Designing accessible content is about removing barriers that make it harder for people with disabilities to access the content, and bad usability is one of those barriers.
> That's wrong, accessibility is about ease of access to the content.
That doesn't account for cognitive disabilities.
Ease of access is up to the user-agent software. Accessibility is more than just that. As front end developers we have to provide that content in a meaningful and understandable form without getting in the browser's or screen reader's way. Sometimes that isn't enough and you need to use ARIA to clarify things more precisely.
> then you could just tell your blind clients to view the page source and read it character by character.
Screen readers provide a variety of navigational tools for drilling into page content. They don't just read text.
I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.
That doesn't account for cognitive disabilities.
Ease of access is up to the user-agent software. Accessibility is more than just that. As front end developers we have to provide that content in a meaningful and understandable form without getting in the browser's or screen reader's way. Sometimes that isn't enough and you need to use ARIA to clarify things more precisely.
> then you could just tell your blind clients to view the page source and read it character by character.
Screen readers provide a variety of navigational tools for drilling into page content. They don't just read text.
I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.
> Screen readers provide a variety of navigational tools for drilling into page content. They don't just read text.
And CSS is also used to provide navigational tools for drilling into page content. For example, putting navigation panels on a sidebar rather than in between the header and the content. That's not just done for aesthetics, it's done to make the information on the page easier to understand. But if your brilliantly-designed page layout breaks when zoomed in, then that is a barrier which disabled people will face that abled people will not. By doing accessibility testing with CSS disabled you will not be able to test the accessibility of such navigational features.
Sure, they could use a screen reader instead, but maybe they don't want to use a screen reader. Maybe page zoom is enough for them normally and that's what they prefer. By not taking accessibility into consideration when creating the visual design of the page, you are basically saying that the visual design of your page is crafted just for the needs of abled people, and disabled people should have to use special tools to access your content. That's inaccessible.
> I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.
You have my point backwards. I am arguing that you can't have great accessibility with bad CSS. Thus you need to do your accessibility testing with CSS enabled (just like how your clients who have disabilities will be using it).
And CSS is also used to provide navigational tools for drilling into page content. For example, putting navigation panels on a sidebar rather than in between the header and the content. That's not just done for aesthetics, it's done to make the information on the page easier to understand. But if your brilliantly-designed page layout breaks when zoomed in, then that is a barrier which disabled people will face that abled people will not. By doing accessibility testing with CSS disabled you will not be able to test the accessibility of such navigational features.
Sure, they could use a screen reader instead, but maybe they don't want to use a screen reader. Maybe page zoom is enough for them normally and that's what they prefer. By not taking accessibility into consideration when creating the visual design of the page, you are basically saying that the visual design of your page is crafted just for the needs of abled people, and disabled people should have to use special tools to access your content. That's inaccessible.
> I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.
You have my point backwards. I am arguing that you can't have great accessibility with bad CSS. Thus you need to do your accessibility testing with CSS enabled (just like how your clients who have disabilities will be using it).
> send HTML as type application/xhtml+xml
What does this change?
What does this change?
> Changing the media type of the HTML does require a bit more strict syntax, but it also is a cheap trick to ensure the HTML tags and structure are arranged in a valid way.
This seems a bit bananas to me because there’s plenty of valid HTML5 is NOT valid XHTML or XML. For example, HTML5 allows common tags such as <p> and <li> to be unclosed, which is not valid in XHTML. HTML5 written in this style is not “wrong” - it’s valid, and correctly presented by tools like VoiceOver. Screen readers will be a-okay with HTML5; this advice is going to send people down wild goose chases with no need.
XHTML is an alternative, dead-end branch of HTML evolution that time has forgotten.
To validate HTML, use an HTML validator.
XHTML is an alternative, dead-end branch of HTML evolution that time has forgotten.
To validate HTML, use an HTML validator.
> HTML5 allows common tags such as <p> and <li> to be unclosed
Yet many people (me included) consider this inappropriate and never use this allowance.
In some cases (when you hand-type/edit huge HTML documents) it is a handy feature but there probably are many scripts that can close the tags for you once you're done.
Yet many people (me included) consider this inappropriate and never use this allowance.
In some cases (when you hand-type/edit huge HTML documents) it is a handy feature but there probably are many scripts that can close the tags for you once you're done.
In modern browsers all modern HTML5 is valid XHTML so long as it conforms to the syntax and tag structure. In fact the only real difference, aside from closing tags like br and img, is that with XHTML the browser yells at you when you get HTML wrong.
On my personal sites I send all my HTML with a .xhtml file extension to force XML compliance, but the code is modern HTML5.
On my personal sites I send all my HTML with a .xhtml file extension to force XML compliance, but the code is modern HTML5.
that is wrong. this is valid html5 for example:
<ul>
<li>content
<li>content2
</ul>
I am aware.
As an additional comment for people coming across this thread in future and anyone else it may help. Please make sure that your accessibility tools are high quality, as you would when assessing any other dependency or service used in the development of your product. In particular, they should always assess the rendered DOM of any page, rather than a string of HTML. And if they make bold claims about the increased accessibility of your website once their recommendations are followed, or try to sell you some ridiculously cheap consultancy services, stay away. Whether you buy their consulting services or not, if they're too cheap, their tools probably are too. And if they tell you that automated testing is a route to complete usability for people with special needs, they're deluded.
For automated testing, try pa11y[0] or Lighthouse (intergrated in Chrome, using web.dev or as a standalone NPM package - (it uses axe-core under the hood)).
Tools will only get you so far, though. To make your site fully accessible, you will need to actually test it yourself. Luckily, most issues can be solved/prevented by following some simple guidelines [1].
Recently, I've reviewed the accessibility of 21 popular CSS UI frameworks [2], so this might be also helpful to you.
[0] - http://pa11y.org/
[1] - https://moritzgiessmann.de/accessibility-cheatsheet/
[2] - https://darekkay.com/blog/accessible-ui-frameworks/
Tools will only get you so far, though. To make your site fully accessible, you will need to actually test it yourself. Luckily, most issues can be solved/prevented by following some simple guidelines [1].
Recently, I've reviewed the accessibility of 21 popular CSS UI frameworks [2], so this might be also helpful to you.
[0] - http://pa11y.org/
[1] - https://moritzgiessmann.de/accessibility-cheatsheet/
[2] - https://darekkay.com/blog/accessible-ui-frameworks/
There is a great Chrome extension called aXe[1], as well as tools like Tenon[2] which also has a rest API so you can potentially set it up as part of a CI workflow.
It's worth remembering that "accessibility" is a broad term. If you want a tool which can identify some common antipatterns and the WCAG guideline(s) they violate, the tools I've mentioned are a good place to start. But if you want to create a truly accessible website which is also usable by people with special needs, you'll need experts to come in to carry out audits and specialised user testing.
Please feel free to drop me an email using the address in my HN profile. I'm a usability and accessibility professional, and disabled to boot. Happy to answer any questions you might have and connect you with other great resources, tools and people.
[1] https://chrome.google.com/webstore/detail/axe/lhdoppojpmngad...
[2] https://tenon.io/
It's worth remembering that "accessibility" is a broad term. If you want a tool which can identify some common antipatterns and the WCAG guideline(s) they violate, the tools I've mentioned are a good place to start. But if you want to create a truly accessible website which is also usable by people with special needs, you'll need experts to come in to carry out audits and specialised user testing.
Please feel free to drop me an email using the address in my HN profile. I'm a usability and accessibility professional, and disabled to boot. Happy to answer any questions you might have and connect you with other great resources, tools and people.
[1] https://chrome.google.com/webstore/detail/axe/lhdoppojpmngad...
[2] https://tenon.io/
Not seen anyone mention it yet, but the Accessibility feature in Firefox (might only be available in Nightly/developer edition, not sure) built into the developer tools are pretty good. You need to go into the dev tools settings to enable it from memory.
It gives you access to what is essentially an "accessibility DOM" that shows you how the page's structure will look to a screen reader, and you can also check the contrast of an elements text against its background.
It might not help you score any better on things like the webmaster tools tests directly, but it might help you identify things to change/fix.
It gives you access to what is essentially an "accessibility DOM" that shows you how the page's structure will look to a screen reader, and you can also check the contrast of an elements text against its background.
It might not help you score any better on things like the webmaster tools tests directly, but it might help you identify things to change/fix.
Just checked in Firefox dev tools: there's a top-level menu for Accessibility, but the panel displays a grayed-out message, "Turn On Accessibility Features" which can't be clicked.
Thanks for pointing out this (future) feature, it sounds very useful. I'll keep an eye out for when it's available.
Thanks for pointing out this (future) feature, it sounds very useful. I'll keep an eye out for when it's available.
Just had a quick read, looks like it's available since Firefox v63, https://developer.mozilla.org/en-US/docs/Tools/Accessibility...
It should work though once you click on that button, weird that it doesn't seem to be working for you.
Edit: Just read through more of that link, it's got quite a good breakdown of the features on it.
It should work though once you click on that button, weird that it doesn't seem to be working for you.
Edit: Just read through more of that link, it's got quite a good breakdown of the features on it.
Thank you for the link, I bookmarked it to read more in detail. You're right, that's a nice overview of the features. I've always felt the need to learn more about accessibility (and regularly apply it to what I build). This looks great for the purpose.
I found in the browser preferences that I'd checked "Prevent accessibility services from accessing your browser". I had to uncheck it to be able to enable the Accessibility Inspector. Will be exploring it more.
I found in the browser preferences that I'd checked "Prevent accessibility services from accessing your browser". I had to uncheck it to be able to enable the Accessibility Inspector. Will be exploring it more.
Also, please don't forget people with hearing impairment. You don't need a special tool, just remember to include text captions or similar if your page includes spoken content.
I'm partially deaf so sensitive to this issue. With hearing aids my hearing is 'fine'. But I recently completed some online training (that had spoken information) with the sound turned completely down to see how bad it would be for a profoundly deaf person. There were two questions where a correct answer required having heard a spoken (but not captioned!) statement.
I'm partially deaf so sensitive to this issue. With hearing aids my hearing is 'fine'. But I recently completed some online training (that had spoken information) with the sound turned completely down to see how bad it would be for a profoundly deaf person. There were two questions where a correct answer required having heard a spoken (but not captioned!) statement.
- If you have little time and money, use any of the automated tools mentioned in the other comments
- If you want the best results, do extensive user testing
- If you are somewhere in the middle, do manual testing yourself. Simply turning on a screen reader and covering the screen with a sheet of paper does wonders.
- Think about accessibility from the start, even before you write the first line of code (just like with security). It is very hard to fix it after the fact.
- If you want the best results, do extensive user testing
- If you are somewhere in the middle, do manual testing yourself. Simply turning on a screen reader and covering the screen with a sheet of paper does wonders.
- Think about accessibility from the start, even before you write the first line of code (just like with security). It is very hard to fix it after the fact.
You can use chrome dev tools. Right click the window and click 'inspect'. In the 'Audits' tab, you can run an audit for accessibility. It runs your website and checks it against common accessibility criteria, giving you a score out of 100.
On a side note, running this page through the accessibility audit, gives a score of 33. Perhaps HN has some work to do on accessibility.
On a side note, running this page through the accessibility audit, gives a score of 33. Perhaps HN has some work to do on accessibility.
HN it's very obviously bad for accessibility, small click/touch targets, grey-on-grey text with v. low contrast in some situations (by design), poor indent-level visibility. Using 'shade of grey' to convey information is never going to be great.
Table-based layout can screw up screen-readers, I assume it's still 'tabulated but non-tabular'. Way back screen-readers used to assume the first tr contained th even if it wasn't marked up that way.
It would be interesting to hear from people who use assistive tech for HN how much of a problem it causes them in practice.
Table-based layout can screw up screen-readers, I assume it's still 'tabulated but non-tabular'. Way back screen-readers used to assume the first tr contained th even if it wasn't marked up that way.
It would be interesting to hear from people who use assistive tech for HN how much of a problem it causes them in practice.
> It would be interesting to hear from people who use assistive tech for HN how much of a problem it causes them in practice.
I use a screen reader and am a frequent reader of HN. Obviously, much of the site's content is textual - you can't include images in comments AFAIK and it's extremely rare for people to link to graphical content as people often do on Reddit. So from that point of view, the site is an oasis away from the often visual nature of the modern web. On the other hand, there is absolutely no way for my screen reader to gauge whether a comment is a child of another, quickly jump past a child thread that I'm not interested in, quickly move up to the parent or grandparent of the current comment, etc.
TL;DR: the content is accessible because it's text, but accessible navigation is non-existent.
I use a screen reader and am a frequent reader of HN. Obviously, much of the site's content is textual - you can't include images in comments AFAIK and it's extremely rare for people to link to graphical content as people often do on Reddit. So from that point of view, the site is an oasis away from the often visual nature of the modern web. On the other hand, there is absolutely no way for my screen reader to gauge whether a comment is a child of another, quickly jump past a child thread that I'm not interested in, quickly move up to the parent or grandparent of the current comment, etc.
TL;DR: the content is accessible because it's text, but accessible navigation is non-existent.
Use aXe for automated tests and test everything manually with JAWS + Firefox (most popular screen reader Desktop combination) and iOS VoiceOver (most troubling mobile issues in my experience).
If you can afford in your project, use a external service that tests with people with different disabilities.
If you can afford in your project, use a external service that tests with people with different disabilities.
JAWS + IE is the most popular combination [1]
[1] https://webaim.org/projects/screenreadersurvey7/#browsercomb...
[1] https://webaim.org/projects/screenreadersurvey7/#browsercomb...
> JAWS + IE is the most popular combination
It's worth keeping a few points in mind when reading these results:
1. The survey was carried out in October 2017. Things can and do move quite rapidly in this area, especially given the increased number of users who will be running Windows 10 now who may not have been back then.
2. IE won't be around forever, and once the accessibility of Microsoft Edge improves (which is likely to happen pretty soon when they adopt Chromium), IE will become less and less relevant.
3. NVDA with Firefox is a much more common combination than JAWS with Firefox, primarily because the NVDA developers recommend it. Freedom Scientific (makers of JAWS) have historically pushed IE perhaps more than other browsers, so it will be interesting to see how that changes as Edge becomes more usable.
It's worth keeping a few points in mind when reading these results:
1. The survey was carried out in October 2017. Things can and do move quite rapidly in this area, especially given the increased number of users who will be running Windows 10 now who may not have been back then.
2. IE won't be around forever, and once the accessibility of Microsoft Edge improves (which is likely to happen pretty soon when they adopt Chromium), IE will become less and less relevant.
3. NVDA with Firefox is a much more common combination than JAWS with Firefox, primarily because the NVDA developers recommend it. Freedom Scientific (makers of JAWS) have historically pushed IE perhaps more than other browsers, so it will be interesting to see how that changes as Edge becomes more usable.
IE is mostly used here because it works best with the screenreaders, not because it's preinstalled or other common reasons. When I test with IE, and then with Firefox, I notice subtle things with big impact working better in IE e.g. I found that screenreaders are particular better with multilingual content on IE. I can't recall the exact screenreader/browser combo, but on IE, I got proper support for different voices for different languages when an element other than the HTML element had a lang attribute.
My only comments to that would be WebAim is the highest authority on accessibility.
I'm well aware that these combinations will change over time.
The biggest thing is that JAWS costs a lot of money, so people buy, get used to it, and stick with their setup.
I tend to say, 'The only people who still use IE have no choice" or something like that.
I'm well aware that these combinations will change over time.
The biggest thing is that JAWS costs a lot of money, so people buy, get used to it, and stick with their setup.
I tend to say, 'The only people who still use IE have no choice" or something like that.
> WebAim is the highest authority on accessibility.
I'm not sure that's strictly true nor measurable, or really matters in this case when we're discussing a survey filled out by users.
I'm not sure that's strictly true nor measurable, or really matters in this case when we're discussing a survey filled out by users.
You're right. Had it wrong in my head.
Hire an engineer who needs accommodation. I mean that in jest of course, but only sort of. For a while I had an engineer on my team who was dyslexic and while not color blind themselves, were very in tune with the color blind community. They made huge improvements on not only our front end UX, but also on our codebase.
For example, apparently camelCase is really bad for dyslexics, and interstitial underscores are always_preferred.
For example, apparently camelCase is really bad for dyslexics, and interstitial underscores are always_preferred.
There are multiple forms of dyslexia. For instance, I have one form and I have a daughter with a completely different variety. I have no problems with camelCase, but I am very particular about my fonts (Consolas for life).
I don’t like _ because of the keyboard placement. I don’t trust my pinkies at those angles.
I don’t like _ because of the keyboard placement. I don’t trust my pinkies at those angles.
My understanding from my coworker was that while some forms of dyslexics can process camelCase no problem, the underscore will never be worse than camelCase and will sometimes be better, so it's better to just use underscore. I'm certainly no expert though.
Pay Knowbility or another specialist (https://news.ycombinator.com/item?id=19475842) - no affiliation with either - to do it for you.
It's a much deeper domain than you think it is and people have real expertise worth paying for, particularly if you need section 508 compliance for a contract and money is on the line.
It's a much deeper domain than you think it is and people have real expertise worth paying for, particularly if you need section 508 compliance for a contract and money is on the line.
We had to do this a few years ago for a major bank. Automated tools like a11y will only get you a certain amount of the way. Your tests will say 100% but your app may still be completely useless to blind people especially if you’re using an SPA as all screen readers perform differently.
Having a partially sighted consultant come in and point out the deficiencies and how they use devices was extremely helpful. A lot of sight impaired people use Apple devices as their voiceover support is excellent, Android is getting better but you will find a lot of differences between their implementations in versions which is extremely frustrating. For desktop on windows JAWS seems to be the most used which again has its own way of parsing.
I don’t know if it’s changed but my advice would be plenty of manual testing, there’s really not much else than actually using the devices with voiceover enabled to test if things actually work properly. And it’s also a case of compromise and picking what devices to support as fixing something on one reader will inevitably break another.
Hope that helps :)
Having a partially sighted consultant come in and point out the deficiencies and how they use devices was extremely helpful. A lot of sight impaired people use Apple devices as their voiceover support is excellent, Android is getting better but you will find a lot of differences between their implementations in versions which is extremely frustrating. For desktop on windows JAWS seems to be the most used which again has its own way of parsing.
I don’t know if it’s changed but my advice would be plenty of manual testing, there’s really not much else than actually using the devices with voiceover enabled to test if things actually work properly. And it’s also a case of compromise and picking what devices to support as fixing something on one reader will inevitably break another.
Hope that helps :)
Lighthouse, available in Chrome devtools, includes an a11y audit although how thorough it is I can't say.
WCAG has historically focused mostly on accessibility for people with physically-manifesting needs (blindness, deafness), but has recently begun working on addressing usability for neurodiverse populations (dyslexia, ADHD, autism).
IMO, this is long overdue, especially considering how large these populations are. Things to consider here relate to text presentation and overall site layout. Think about text sizing/contrast, line spacing, column width, and paragraph height, for example. And consider how each of these things changes when the user is on mobile (paragraphs are now much taller, creating the "wall of text" that many people dread).
IMO, this is long overdue, especially considering how large these populations are. Things to consider here relate to text presentation and overall site layout. Think about text sizing/contrast, line spacing, column width, and paragraph height, for example. And consider how each of these things changes when the user is on mobile (paragraphs are now much taller, creating the "wall of text" that many people dread).
There is a new tool from Microsoft/Axe partnership. Microsoft is one of the leaders in Accessibility. Partnering with Axe (Deque), the tool not only has a fast checker, it shows both on the site and in the report where the problems are, links to exact WCAG rules and has guidelines how to fix. All Open Source.
Chrome extension:
https://chrome.google.com/webstore/detail/accessibility-insi...
You've received a lot of recommendations for software, but one of the most important things to bear in mind is that software cannot ensure accessibility. It can discover some problems with accessibility, but it has a lot of blind spots. If you care about accessibility, you need to incorporate manual human testing. This is a highly specialised field. The best thing for you to do is to fix the low-hanging fruit by plugging automated tools into your CI system, then get an expert to do a manual test so that you're aware of what other issues there are.
I can think of only one tool that will test, score and identify accessibility issues, as well as track progression/regression over time. A testing tool provided by User1st. uTester
That said, automated testing can test anywhere from 30-40% of WCAG, leaving the rest to be found by a manual review. If you are not familiar with JAWS, NVDA, VoiceOver or TalkBack then a large portion of WCAG on your site(s) will go un-tested.
http://www.user1st.com/services/
That said, automated testing can test anywhere from 30-40% of WCAG, leaving the rest to be found by a manual review. If you are not familiar with JAWS, NVDA, VoiceOver or TalkBack then a large portion of WCAG on your site(s) will go un-tested.
http://www.user1st.com/services/
Don't forget to check your website with a colorblindness simulator. This is a manual process unfortunately
Also with things like high contrast, high zoom level or increased font size, etc
Also with things like high contrast, high zoom level or increased font size, etc
https://www.compliancesheriff.com/
Compliance Sheriff helps identify compliance issues with WCAG and Section 508 standards, and their scan will give output with visual indicators of the non-compliant areas. Haven't seen that in any other tool.
They have a free test for up to 10 publicly facing URLs too.
Compliance Sheriff helps identify compliance issues with WCAG and Section 508 standards, and their scan will give output with visual indicators of the non-compliant areas. Haven't seen that in any other tool.
They have a free test for up to 10 publicly facing URLs too.
1. Install NVDA
2. Read part 4 from user guide
https://www.nvaccess.org/files/nvda/documentation/userGuide....
3. turn off your monitors
4. try to do simple smock test
One tool, not mentioned so far, is tota11y: http://khan.github.io/tota11y/
It gives a bunch of inline annotations for accessibility problems and points of concern. Not sure how it compares with the others suggested, but might be useful to try.
It gives a bunch of inline annotations for accessibility problems and points of concern. Not sure how it compares with the others suggested, but might be useful to try.
Here's one: https://achecker.ca
I used your checker on https://news.ycombinator.com/newcomments and it gives 38 known problems and 384 potential problems.
Ask me to look at it: 39 days ago, on this very site, I learned that I am what is called by cognoscenti a "breaker": https://news.ycombinator.com/item?id=19153810
I have this, but with typos. Give me a page full of text with a single typo, and somehow, against all odds, I'll immediately spot it.
Me too! I just got an email from Cory Doctorow re: a typo I found in his article. It"s my only super power
Too bad copyreaders are a dying profession 'cause you'd be a natural.
A lot of good suggestions here already, but in terms of screenreaders, JAWS has a majority stake in the market. They make a tool call JAWS Inspect which gives you reports (and by extension, version control) over your screenreader presentation. It's not free though.
Switch the language option if one exists and try using the website in a language you don't understand. Has helped immensely for my side projects in improving UI clarity and ease of navigation.
I'm also looking for something similar: you give it a list of routes and it will score each of them.
Doing this manually with Chrome's Audit tool for each route is time consuming.
Doing this manually with Chrome's Audit tool for each route is time consuming.
I've used the Wave extension for Chrome.
Also, being able to use the website with a screen reader (with your eyes closed) is a good metric.
Also, being able to use the website with a screen reader (with your eyes closed) is a good metric.
Wave also has firefox extension http://wave.webaim.org/extension/ and webapp http://wave.webaim.org/
Try viewing it in lynx and navigating with keyboard commands only in lynx, to see how it will work for a screen reader tool.
Firefox recently added an accessibility inspector in the dev tools which may be of use.
Just wanted to say thanks to everyone for all the super helpful responses in here!
[deleted]
Try to browse it with NetSurf!
Check out http://www.sitespeed.io
There are maybe 10 well known tools for doing such things, easily Google-able, including Google's tools, that web developers everywhere have been using for ages but I'm on my phone at an airport so I'll try and post them tonight.
Pa11y
Disable javascript and see if it still works.
If not, what are some best practices people use to maintain accessibility? Does anyone write tests for this functionality? Would love to learn more, top resources, checklists people use, etc.