Live data from Hacker News

Building the most inaccessible site with a perfect Lighthouse score (2019)

matuzo.at

11–20 of 42 posts

Re: Building the most inaccessible site with a perfect Lighthouse score (2019)

#11
post #3

My personal takeaway from this is that automated accessibility tests are no substitute for professional audits

I get the feeling that a professional audit has a reasonable chance of being the output from lighthouse copied into a spreadsheet. If I'm going to get shallow automated advice, I want it cheap and fast, from the source.

My last job had audits done on a semi-yearly basis and they always caught things our automated tests hadn't.

Broad stuff like providing controls for changing content (e.g. carousels) are what automated a11y tests fail on; other hard-to-test criteria includes WCAG 2.1§2.3.1 "Three Flashes or Below Threshold" and 1.4.9 forbidding "Images of Text"

Re: Building the most inaccessible site with a perfect Lighthouse score (2019)

#14
post #5
post #3

My personal takeaway from this is that automated accessibility tests are no substitute for professional audits

An audit, and using the site as a person who requires accessibility would while developing. The automated tools are just a quick check to find anything blatantly wrong. I also suggest using WAVE and AXE for that purpose. As you get deeper into accessibility you'll also find there isn't one single right answer to improve accessibility.

> … there isn't one single right answer to improve accessibility.

This is very true. Like any optimization, there is a point at which improving things for one community makes things worse for others. An example most of us are familiar with are the trade offs between mobile UI and desktop UI: You can make your UI adequately work on both, but in order to give both an optimal experience things start to get quite complex. I’ve seen developers tie themselves into knots trying to be all things to all people here. Accessibility is harder in a sense because able-bodied devs often don’t have any instinct for when they’re crossing the line from “good enough” to “overkill”.

The 80% rule for accessibility is really just “Make your site keyboard accessible”. While there will still be some issues for some users, it’s a clear enough goal that it can break a dev out of “analysis paralysis” and just get moving on something, and the benefit is huge for the vast majority.

Re: Building the most inaccessible site with a perfect Lighthouse score (2019)

#16
post #3

My personal takeaway from this is that automated accessibility tests are no substitute for professional audits

Accessibility is just usability. You cannot automate usability tests. You have to put it in front of a real human and see if they can use it.

> Accessibility is just usability.

Common thought, but not really true. The basics of accessibility might be considered just "usability" or even UX, but going beyond that, it steps in being useful for people with certain disabilities while not impacting people without.

One example from the article, `aria-hidden="true"` (https://www.w3.org/TR/wai-aria/#aria-hidden) might be used to hide elements containing text that are not useful for people with screen-readers, while not changing the experience at all for the ones not using one.

Re: Building the most inaccessible site with a perfect Lighthouse score (2019)

#17
> This post is about you and me. Scores indicate the quality of our apps and sites, but we must not trust these numbers thoughtlessly. We have to understand that automatic testing is just a first step.

I run my own scoring tool website best practices and SEO, and often get support requests from users who are worried or annoyed they can't get a perfect score. Some of my general views here:

- Scores serve more as a minimal baseline that your site should meet and there's always limitations to what the score measures. A low score means it's very likely there's some bad issues to fix and a high score means your site is probably in good shape, but this should only be used as a starting point. You can usually trick scoring tools as well so the score is assuming you're playing fair.

- Perfects scores usually aren't possible for non-trivial sites. There's always trade-offs to make, including if it's worth a large development effort to fix something that's not a big deal. Only you can decide what's worth the effort to fix and what your site's audience will care about most.

- Because of the above, it's not usually meaningful to make in-depth comparisons of scores from different sites. Scores are better used as a rough metric to tell if your own site is improving after you make changes.

Re: Building the most inaccessible site with a perfect Lighthouse score (2019)

#18
post #15

If only he'd used his talents for good, not evil. Seriously, though, I swear I've encountered some of these before. If TBL was dead, he'd be rolling in his grave.

Motive for being evil:

> This is so evil. My LinkedIn inbox will be filled with job offerings by companies like Facebook and Uber.

Re: Building the most inaccessible site with a perfect Lighthouse score (2019)

#20
post #4

A bit silly. Most of the examples are intentionally hiding content with explicit commands no one would ever use, and then saying it is inaccessible. That said, Lighthouse should do things like "use perceptual parsing trchniques to compare the visible content to the standard screen reader parsed content".

> intentionally hiding content with explicit commands no one would ever use

Try browsing the web with JS and/or CSS disabled, you may be surprised to see how common it is to use and equivalents.

Just by disabling JS and occasionally using keyboard navigation, I have personally noticed half of the techniques in the article on major websites.

Post reply on HN