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.
Couple of issues I spotted:
- You're recommending a maximum meta description length of 320. That's no longer what Google recommends.
- I got all green ticks for mobile scaling on a site with "maximum-scale=1". Maximum scale should ideally be avoided.
Thanks, can you provide a link that gives a length recommendation? On https://developers.google.com/search/docs/beginner/seo-start... they say:
"While there's no minimal or maximal length for the text in a description meta tag, we recommend making sure that it's long enough to be fully shown in Search (note that users may see different sized snippets depending on how and where they search)"
This one is tricky because the maximum number of characters Google displays is open to change (and there's more search engines than only Google too).
> I got all green ticks for mobile scaling on a site with "maximum-scale=1". Maximum scale should ideally be avoided.
Thanks, I'll look into this. Rule https://www.checkbot.io/guide/seo/#rule-set-mobile-scaling is only checking for `width=device-width, initial-scale=1` right now (cited from https://developers.google.com/search/mobile-sites/mobile-seo...) and not looking at `maximum-sale`, so this falls under being a decent baseline but still more you could do.
What range of `maximum-scale` should be allowed if any? Off the top of my head, `1.1` is probably just as bad but `100` is probably okay. I'm curious what the typical values used are.
In general, I've been pretty conservative about what rules I've added, sticking to ones that are generally agreed on and generate minimal false positives.
Seriously, though, I swear I've encountered some of these before. If TBL was dead, he'd be rolling in his grave.
> This is so evil. My LinkedIn inbox will be filled with job offerings by companies like Facebook and Uber.
People really get offended by the middle finger emoji? Wow.
You might feel some moral high ground by abandoning all tradition and traditional social contracts, but those traditions and traditional social contracts are still held in high regard by many many people.
It doesn't have anything to do with abandoning tradition and living the edgelord life; the middle finger is firmly up there with "crap" or "bugger" on the "people were using this in ads 15 years ago" end of the offensive spectrum.
I suspect this is why my LCP is crap. But I'm unsure of a way to make the lighthouse score better without removing the glide animation. Do I have no recourse?
That said, Lighthouse should do things like "use perceptual parsing trchniques to compare the visible content to the standard screen reader parsed content".
Try browsing the web with JS and/or CSS disabled, you may be surprised to see how common it is to use <body hidden> 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.
> btw guys this isn't really about accessibility guidelines it's just about, uh, the importance of not relying on those guidelines, or something. totally not me venting about having to follow accessibility guidelines in the first place as many of my professional colleagues are known for doing.
As you get deeper into accessibility you'll also find 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.
If I'm going to get shallow automated advice, I want it cheap and fast, from the source.
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"
You cannot automate usability tests. You have to put it in front of a real human and see if they can use it.
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.
Where something is explicitly visual-only, I agree that there can be cases.