Hacker News new | ask | show | jobs
by throwaway857384 2648 days ago
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/

5 comments

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

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.

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!

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/

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.

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