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.
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/
Thanks for any pointers!
[1] https://www.levelaccess.com/ [2] https://www.deque.com/ [3] https://www.paciellogroup.com/
[1] https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechan...
If you tab out of the URL bar of your browser, Facebook has a huge accessibility skip links menu.
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.
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/
- 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 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 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 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.
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.
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.
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.
These are also good UX guidelines in general.
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.
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'm not sure how this is related to accessibility? Are there tools for visually impaired people that don't work well with JS?
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.
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.
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
What does this change?
XHTML is an alternative, dead-end branch of HTML evolution that time has forgotten.
To validate HTML, use an HTML validator.
On my personal sites I send all my HTML with a .xhtml file extension to force XML compliance, but the code is modern HTML5.
<ul>
<li>content
<li>content2
</ul>
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.
They might. You probably mean blind people.
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.
> 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.
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.
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.
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 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.
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).
For example red means stop and green means go to many people. When color is the primary means of status description that is discriminatory, because blind people cannot perceive color in any way. The status must be described in some other way equally for all users, but it can be colored red/green by CSS for increased usability. The same goes for page structures like menu bars. The standards even provide examples with ARIA.
CSS is only a factor for people with motor control limitations when interactive controls are too close together to be accessed uniquely with a mouse click. If this is a concern for you have somebody with advanced Parkinson’s usability test your site, otherwise turn CSS off for all other accessibility testing.
Yes, agreed. That's why you should provide a non-colour-based indicator of the status, AND ALSO make sure the colours work for partially vision impaired people (or colourblind, etc).
If the information is technically accessible, but in an awkward and hard-to-use format compared to the sighted version of that information, then it's not really accessible. Making colourblind people read awkward labels when you could just as easily use colourblind-compatible colours is inaccessible. I am not confusing presentation and semantics, I am just saying that both are involved in creating accessible content.
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/
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...
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.
Thanks for pointing out this (future) feature, it sounds very useful. I'll keep an eye out for when it's available.
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.
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'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 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.
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.
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.
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.
If you can afford in your project, use a external service that tests with people with different disabilities.
[1] https://webaim.org/projects/screenreadersurvey7/#browsercomb...
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.
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 not sure that's strictly true nor measurable, or really matters in this case when we're discussing a survey filled out by users.
For example, apparently camelCase is really bad for dyslexics, and interstitial underscores are always_preferred.
I don’t like _ because of the keyboard placement. I don’t trust my pinkies at those angles.
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.
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 :)
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).
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.
Also with things like high contrast, high zoom level or increased font size, etc
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.
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.
Doing this manually with Chrome's Audit tool for each route is time consuming.
Also, being able to use the website with a screen reader (with your eyes closed) is a good metric.