
Ask HN: Best way to test accessibility of a website? - pcmaffey
Is there a bot&#x2F;crawler akin to Google&#x27;s Webmaster Tools that will test, score, and identify accessibility issues on a website?<p>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.
======
throwaway857384
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...](https://chrome.google.com/webstore/detail/axe-
coconut/iobddmbdndbbbfjopjdgadphaoihpojp?hl=en) [2]
[https://chrome.google.com/webstore/detail/headingsmap/flbjom...](https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en)
[3] [https://www.nvaccess.org/](https://www.nvaccess.org/)

~~~
IvarTJ
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...](https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-
skip.html)

~~~
tmaxxcar
Skip-links should also be accessible for keyboard users.

~~~
throwaway857384
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.

------
dbjorge
Microsoft recently open sourced[1] one of the main tools they use for web
accessibility testing.

Accessibility Insights for Web
([https://accessibilityinsights.io](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...](https://cloudblogs.microsoft.com/opensource/2019/03/12/microsoft-
open-sources-accessibility-insights/) [2]
[https://www.deque.com/axe/](https://www.deque.com/axe/) [3]
[https://www.w3.org/WAI/WCAG21/quickref/](https://www.w3.org/WAI/WCAG21/quickref/)

~~~
scrollaway
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.

------
dingus
\- 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.

~~~
warent
> "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.

~~~
uberswe
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.

------
austincheney
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

~~~
interfixus
> _Vision impaired persons do not benefit from CSS or images_

They might. You probably mean blind people.

~~~
austincheney
No, I mean vision impaired. There are all kinds of different vision
disabilities besides blindness and color blindness.

~~~
interfixus
Yes, exactly. And many such impairments will not prevent you benefitting from
layout, colors, typography, images, and sundry other kinds of graphical
trickery.

~~~
austincheney
Sounds like you are confusing non-blindness for normal functionality.
Fortunately, Wikipedia has a page for this:
[https://en.wikipedia.org/wiki/Visual_impairment](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.

~~~
shawnz
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.

~~~
austincheney
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.

~~~
shawnz
> Well written CSS, a subset of usability, is irrelevant to accessibility.

Says who?

[https://www.w3.org/WAI/fundamentals/accessibility-
usability-...](https://www.w3.org/WAI/fundamentals/accessibility-usability-
inclusion/#accessible-usable)

> 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.

~~~
austincheney
> 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.

~~~
shawnz
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.

~~~
austincheney
> 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.

~~~
shawnz
> 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).

~~~
austincheney
You are deliberately confusing presentation for semantics, which is
discriminatory. The WCAG directly mentions not doing this. You cannot achieve
AA conformance when you attempt to force this on your users.

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.

~~~
shawnz
> 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

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.

------
jscholes
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.

------
darekkay
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/](http://pa11y.org/)

[1] - [https://moritzgiessmann.de/accessibility-
cheatsheet/](https://moritzgiessmann.de/accessibility-cheatsheet/)

[2] - [https://darekkay.com/blog/accessible-ui-
frameworks/](https://darekkay.com/blog/accessible-ui-frameworks/)

------
jscholes
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...](https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd)

[2] [https://tenon.io/](https://tenon.io/)

------
philo23
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.

~~~
lioeters
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.

~~~
philo23
Just had a quick read, looks like it's available since Firefox v63,
[https://developer.mozilla.org/en-
US/docs/Tools/Accessibility...](https://developer.mozilla.org/en-
US/docs/Tools/Accessibility_inspector#Accessing_the_Accessibility_Inspector)

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.

~~~
lioeters
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.

------
KineticLensman
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.

------
ximm
\- 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.

------
longnow
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.

~~~
pbhjpbhj
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.

~~~
jscholes
> 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.

------
oh_boy
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.

~~~
throwaway857384
JAWS + IE is the most popular combination [1]

[1]
[https://webaim.org/projects/screenreadersurvey7/#browsercomb...](https://webaim.org/projects/screenreadersurvey7/#browsercombos)

~~~
jscholes
> 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.

~~~
throwaway857384
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.

~~~
jscholes
> 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.

------
throwaway5752
Pay Knowbility or another specialist
([https://news.ycombinator.com/item?id=19475842](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.

------
jedberg
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.

~~~
cwbrandsma
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.

~~~
jedberg
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.

------
bazza451
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 :)

------
ioddly
Lighthouse, available in Chrome devtools, includes an a11y audit although how
thorough it is I can't say.

------
gnicholas
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).

------
Sumner19
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...](https://chrome.google.com/webstore/detail/accessibility-insights-
fo/pbjjkligggfmakdaogkfomddhfmpjeni?hl=en)

------
JimDabell
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.

------
tmaxxcar
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/](http://www.user1st.com/services/)

------
raverbashing
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

------
dta5003
[https://www.compliancesheriff.com/](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.

------
zxxc
1\. Install NVDA 2\. Read part 4 from user guide
[https://www.nvaccess.org/files/nvda/documentation/userGuide....](https://www.nvaccess.org/files/nvda/documentation/userGuide.html?#GettingStartedWithNVDA)
3\. turn off your monitors 4\. try to do simple smock test

------
alangpierce
One tool, not mentioned so far, is tota11y:
[http://khan.github.io/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.

------
bookofjoe
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](https://news.ycombinator.com/item?id=19153810)

~~~
majewsky
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.

~~~
bookofjoe
Too bad copyreaders are a dying profession 'cause you'd be a natural.

~~~
majewsky
Eh, it's not like I crave copyreading. So I don't mind being automated away by
spell checkers in that department.

~~~
bookofjoe
FWIW,since the Washington Post effectively fired all its copyreaders, there
have been significantly more errors, as noticed by this close
reader/subscriber.

------
gtirloni
Here's one: [https://achecker.ca](https://achecker.ca)

~~~
xorand
I used your checker on
[https://news.ycombinator.com/newcomments](https://news.ycombinator.com/newcomments)
and it gives 38 known problems and 384 potential problems.

------
SpaceL10n
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.

------
hikergirl1234
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.

------
sfusato
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.

------
walrus01
Try viewing it in lynx and navigating with keyboard commands only in lynx, to
see how it will work for a screen reader tool.

------
winrid
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.

~~~
zczc
Wave also has firefox extension
[http://wave.webaim.org/extension/](http://wave.webaim.org/extension/) and
webapp [http://wave.webaim.org/](http://wave.webaim.org/)

------
pcmaffey
Just wanted to say thanks to everyone for all the super helpful responses in
here!

------
baroffoos
Firefox recently added an accessibility inspector in the dev tools which may
be of use.

------
netrap
Try to browse it with NetSurf!

------
Favic0n
Check out [http://www.sitespeed.io](http://www.sitespeed.io)

------
ykevinator
Pa11y

------
sha666sum
Disable javascript and see if it still works.

------
sureaboutthis
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.

