Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

matuzo.at

Post reply on HN
Print view View original

51–60 of 81 posts

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

#51

Post by redis_mlc »

ChrisMarshallNY wrote: post #41
naringas wrote: post #17

Earlier quoted context omitted.

>I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product. I agree, but then they need to be equally well payed... and I don't think it is possible to find a manager willing to pay them as much

I worked for a Japanese company that was renowned for Quality (with a capital "Q"). In the US, having "Quality" in your title often means that you are in a dead-end job. In that company, it meant that you were an elite, and that you had considerable power over Engineering. It also meant that you were a completely anal-retentive S.O.B. They had spreadsheets with 3,000 rows (each row was a test -usually "monkey" test).…

> The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it.

Some more details about that behavior are:

In Japan, employees start with a zero score, then for each mistake lose a point. So they will analyze/block anything that could potentially cause a demerit. Obviously that's the polar opposite of "move fast and break things."

Regarding the "3,000 line spreadsheet", yup, that's normal there and part of why their meetings often run to midnight. Gotta check and double-check every row before moving on to the next one. :)

If you want to learn more about these cultural differences, read patio11's excellent posts about working in Japan.

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

#52

Post by redis_mlc »

ChrisMarshallNY wrote: post #15

One of the "philosophers' stone" goals of the software industry is to completely replace human testing with automated testing. Basically, I think automated testing is a very good thing, and we should definitely try to do as much of it as possible. So we can clear the way for more useful and meaningful human testing. I've always thought that the engineers in QC should be just as skilled and qualified as the ones build…

> One of the "philosophers' stone" goals of the software industry is to completely replace human testing with automated testing.

Generally the people who say that don't have a clue - I meet them monthly: "We can save X money by writing a Selenium script and firing the whole QA team!" is typical.

I'm managed QA teams at a few companies in telco, boxed software and SaaS.

And people invariably get all huffy when I say, "Are you going to assign one of your programmers to review changed screens before integration and deploy?"

Then suddenly their eyes glaze over since they just lost a partial headcount and accepted even more responsibility for the release.

What I want are world-class manual testers that understand all of the product features, know how to approach testing it, what the problem areas are, and can communicate the issues to developers.

Luckily I know a few, and I wouldn't call what they do "monkey-testing" at all - their opinion of a release's quality is the only one that actually counts to me.

What I don't want are programmers writing Selenium scripts with no understanding of the product, then moving on to some other project and abandoning half-done tests. That's what you get when you fire your QA team.

> I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product.

World-class QA people are skilled at manual testing. World-class automated test programmers are not QA, they're called programmers.

For developers, what you can do is make the software you write testable. For web applications, add id's to all buttons for example, which are usually required for automated testing software to know what to specify.

Also, if you crapped out a feature (did a copy and paste of other code with "it works for me" local testing), just tell your QA person, "I crapped it out. Please take a look." so they know they'll need extra time to look at it.

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

#53

Post by bhrgunatha »

An Interesting and entertaining article.

The most interesting part to me (as someone with vision problems) was the WebAIM link [1]. The biggest problem I have is with the almost total blind adoption of low contrast (so often too low for me to even read) and sure enough the section about low contrast [2] says:

"found on 86.3% of home pages. _This was the most commonly-detected accessibility issue_.

My basic question then is why do so many designers and websites choose to break the WCAG guidelines?

[1] https://webaim.org/projects/million

[2] https://webaim.org/projects/million/#contrast

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

#54

Post by ChrisMarshallNY »

redis_mlc wrote: post #51
ChrisMarshallNY wrote: post #41

Earlier quoted context omitted.

I worked for a Japanese company that was renowned for Quality (with a capital "Q"). In the US, having "Quality" in your title often means that you are in a dead-end job. In that company, it meant that you were an elite, and that you had considerable power over Engineering. It also meant that you were a completely anal-retentive S.O.B. They had spreadsheets with 3,000 rows (each row was a test -usually "monkey" test).…

> The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it. Some more details about that behavior are: In Japan, employees start with a zero score, then for each mistake lose a point. So they will analyze/block anything that could potentially cause a demerit. Obviously that's the polar opposite of "move fast and break things." R…

> their meetings often run to midnight.

I still have PTSD from that.

Nothing quite like a 14-hour flight, massive jet lag, and an all-day (and all-night) meeting in a packed, cramped, overheated conference room.

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

#55

Post by chrismorgan »

Another technique to mess up keyboard users: don’t use the document scroll area, but make your own (and don’t focus it or anything in JavaScript). Thus the user will have to press Tab or click in the area before keyboard navigation keys will work. So for best results put a large number of focusable elements before the scrollable pane, so that the keyboard user must press Tab a large and unpredictable number of times before it works.

It’ll be something like this:

  
    
    
    
    
      …
You could probably mess with other tabindexes (randomly jump through the document with Tab!) without Lighthouse baulking.

I was going to suggest adding `pointer-events: none` so that the user can’t just click to focus it, but that was already done!

(I mentioned focusing your scroll area element as something you need to do if you roll your own rather than using the document scroll area; but that’s not all you need to do. You also need to monitor blur events and change any .blur() calls, so as to avoid the document element ever retaining focus. It inherently depends on JavaScript, and is very fiddly to get fully right—I’m actually not sure if anyone gets it fully right; the interactions of focus and selection are nuanced and inconsistent, and it’s extremely easy to mess up accessibility software; I haven’t finished my research on the topic. I strongly recommend against the technique on web pages; web apps can occasionally warrant it.)

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

#56

Post by aww_dang »

luckylion wrote: post #6

Imho, the problem with Lighthouse (and Pagespeed before it) isn't that they're not perfect, it's that they assign scores/grades. When Google assigns a score to something, people understand it to mean highest score = best and start optimizing for the grade Google gives them, not for performance and user experience, which the grade is supposed to represent. It would be more fruitful to list the issues and their severit…

Depends on what the right thing is in your specific context. If you drop from 100% to 98% but increase your conversion rate 5x, the trade off should be obvious.

From my experience anything 95% or better is basically perfect. Although stuff like "time to first byte" might impact the number of pages crawled when you have millions of pages etc. There will always be edge cases.

The article makes a funny point, but I'm not sure it is a practical one. Who would honestly go through those steps? Maybe someone copy-pasting or installing templates could make a few of those errors?

Overall the score is helpful and the specific errors detected are always visible in the breakdown below the score. As with anything if you don't understand the underlying technology, tooling and metrics can be troublesome. In those cases, a simple score is still better than giving a novice developer a complex breakdown.

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

#57

Post by yongjik »

ChrisMarshallNY wrote: post #41
naringas wrote: post #17

Earlier quoted context omitted.

>I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product. I agree, but then they need to be equally well payed... and I don't think it is possible to find a manager willing to pay them as much

I worked for a Japanese company that was renowned for Quality (with a capital "Q"). In the US, having "Quality" in your title often means that you are in a dead-end job. In that company, it meant that you were an elite, and that you had considerable power over Engineering. It also meant that you were a completely anal-retentive S.O.B. They had spreadsheets with 3,000 rows (each row was a test -usually "monkey" test).…

Totally unrelated, but your anecdote reminds me of Japan's WW2-era history - the animosity between the Imperial Army and Navy was so bad that the army built their own submarines.

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

#58

Post by aww_dang »

the_pwner224 wrote: post #29
anoncareer0212 wrote: post #22

Earlier quoted context omitted.

I'm not sure the argument in your post or the parents hold water - lighthouse scores aren't a "judge, jury, and executioner" sometimes dev tools are just dev tools, and nothing is perfect.

Wouldn't be surprised if they use it in search rankings, chances are they already do. And not being on Google effectively == dead. They already take into account page load speed (which discriminates against complex but useful & good web apps) and iirc also whether you have AMP.

Do a test and compare your own optimized site to an amp site. See if you can't beat it. Not that hard when you consider the 3rd party requests amp requires.

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

#59

Post by CivBase »

luckylion wrote: post #6

Imho, the problem with Lighthouse (and Pagespeed before it) isn't that they're not perfect, it's that they assign scores/grades. When Google assigns a score to something, people understand it to mean highest score = best and start optimizing for the grade Google gives them, not for performance and user experience, which the grade is supposed to represent. It would be more fruitful to list the issues and their severit…

Yeah, I don't use static analysis tools to "grade" my code. I use them to automatically find simple issues I might have overlooked. If ESLint doesn't find any issues, it doesn't mean my Javascript is actually good. It just means it isn't bad in the ways ESLint is looking for.

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

#60

Post by twoclicksnorth »

luckylion wrote: post #6

Imho, the problem with Lighthouse (and Pagespeed before it) isn't that they're not perfect, it's that they assign scores/grades. When Google assigns a score to something, people understand it to mean highest score = best and start optimizing for the grade Google gives them, not for performance and user experience, which the grade is supposed to represent. It would be more fruitful to list the issues and their severit…

When a measure becomes a target, it ceases to be a good measure.
Post reply on HN