Don’t Use Web•dev for Accessibility Info

Web.dev is a site from Google Chrome developer relations that provides content both to evangelize Chrome and to more broadly support the web platform. Rachel Andrew’s monthly “new to the platform” posts are effectively required reading to try to stay abreast of the browser support landscape.

The web.dev logo of a right angle bracket and dot, but there is question mark added to the dot.

However, the accessibility content in many of Web.dev’s articles and posts is problematic.

My experience is a function of either stumbling across posts on my own or developers treating accessibility guidance in one of its articles as gospel — even when it is demonstrably wrong or harmful.

Examples

Generally the content is not written by digital accessibility experts, so there are bound to be errors; we all make mistakes. This excludes the dedicated accessibility training material, which I have not reviewed.

I have corrected some articles as free labor:

I had made a video for that last one
Recorded in June 2022, I am showing the missing accessible name in the Chrome developer tools and then manually adding it to confirm the fix.

Here is an issue (not pull request or edit) with a good interaction and outcome:

These were examples where I was happy to donate my time because the impact on users of potentially incorrect information warranted it. But then I filed an issue on a post for an …accessible tooltip custom element that encoded WCAG violations — barriers for users and legal risk for developers:

The author participated briefly, but never addressed the problems. When the issue moved to a new issue tracker, nobody from Web.dev participated any further and the original incorrect article has persisted since October 2022:

Most recently a dev directed me to two articles that provided poor guidance on tabindex. This dev was using the articles to justify creating a WCAG-failing pattern, so I filed two issues:

In each of those eight cases I encourage you to read the issue, the interaction, the timeline, and the resolution (if any) and decide if you think the issues and outcomes were adequate.

Please note that these are the cases where I took the time to file issues. I have had many more cases over the past few years that I did not track but where I counseled someone to ignore a Web.dev article at least in part.

Other Factors

When I visit a web site I tend to look for signals for whether I can trust it. I was informed one of those tabindex articles was from 2016 and had been updated since then, hence the four authors. I realized there was no way for a casual reader to know that.

Factors on Web.dev that lead to my general wariness:

This means that you can click the top-most article in the index and not know when it was actually published, if it has been updated, how many times it has been updated, and what was updated.

The web.dev articles index on page 1 with the article ‘Modify DOM order with tabindex’ in the eighth position out of 12. The web.dev articles index on page 3 with the article ‘Accessibility for web developers’ in the tenth position out of 12.
I captured these images on 5 July 2024. They are presented in order of update date. Modify DOM order with tabindex, from 2016, appears immediately after an article posted no earlier than 16 May (based on the embedded YouTube video). Accessibility for web developers has a February 2024 update date, but no indication when it was originally published. .

If you copy code which results in all sorts of breakage, then later go back to the article to confirm it and find the code is now different, you will only know because you looked for it. The update date can at least confirm something changed, but then you have to run a diff to find what changed.

What about when you share it with a client or vendor or co-worker? How will you know the thing you wanted them to read is the same?

This assumes a fix to an article is not lost at some future date, too.

These factors trigger revisionist history alerts in my brain. At no point can you as a casual reader know something changed. Even when I knew a change was coming, I had to keep the original page open so I could compare it with the update to know how it changed.

This is a terrible way to build trust in your content.

As a truly solo writer (yes, that’s a callback if you read the tool-tips issue), I have learned that including the original publication date, the most recent update date, and date-stamping all my updates helps ensure I am not mismanaging expectations or retconning my posts (the date in the URL contributes as well). I try to be honest about when I get my posts wrong and have to clean them up, along with how and why.

The Site Itself

A beat-up old computer, keyboard and monitor all as one piece, with a yellowed piece of paper taped over half the screen; the paper has the word “FAIL” in large red letters at the top, and below it is a checklist.

In January 2023 I wrote Comparing Manual and Free Automated WCAG Reviews. I wanted to use a site with a rich collection of WCAG failures, both familiar and novel, and the Web.dev home page fit the bill.

On the Web.dev home page I found 18 WCAG violations across 37 unique issues (from 180 distinct instances), though only 2 were critical. Nearly any automated tool would have picked up a handful of these.

I even used the Web.dev home page to educate a WCAG tester on how to evaluate how trustworthy a reference site might be, which I shared on Twitter.

Recorded in January 2023, this shows me using the Chrome developer tools to expose the video player and then toggle the reduced-motion settings, which has no effect on the video.

Beyond that now-ancient home page, WCAG risks are easy to find.

Within individual articles, links are still differentiated by color alone (a technical WCAG pass but knowingly problematic for users).

After being greeted repeatedly by auto-playing videos with no way to stop them (though the authors have fixed them when I asked), I made a bookmarklet to restore controls to videos specifically for this site.

Readers have filed other accessibility bugs, such as horizontal scroll, text contrast, auto-playing videos (Chrome dev blog too), broken skip link, contrast of controls, and focus order.

Those are the readers who got past the disability-wall the new bug tracker throws in front of first-time bug reporters.

A modal dialog titled “Google IssueTracker Terms of Service”. It is followed by a checkbox alongside the text “I acknowledge and agree to the Google Terms of Service (link) and the Google IssueTracker Conduct Policy (link).” Below all this is a disabled “OK” button.
That checkbox has no accessible name. The text next to it is not programmatically associated.

It doesn’t comfort me as someone filing bugs that many of these existing bug reports collect spam.

Wrap

Posting this means some people there will take it personally. That sucks and I feel for them. But I have chosen to share this because I believe content that suggests other devs encode barriers in their projects (leaving disabled users stranded) is a far worse outcome than maybe hurting some feelings. I want Web.dev as a whole to learn, its authors to be able to advocate for more support from the mother ship of Google, and never again feel they are a solo author.

Please do not use this post as an excuse to beat up anyone at Google. If you are doing that, you have missed the point of this post and you are being unnecessarily mean to individuals who may have no control over broader organizational decisions. Do not be that guy / person / jerk. This is an organizational failure.

There are genuinely good people doing important work. I reference some of the content on the regular because of the good work of those people, but I still caveat it so nobody considers it an endorsement of any other content. I hate that. I don’t want to do that.

2 Comments

Reply

I’m really glad to see you raised the point on publication dates and change history. Many articles and blog posts no longer seem to provide this information. Of course on a personal blog authors can do as they please. But if they are providing information that might be referenced in some way, a fixed publication date is really important, since information can date very quickly.

Reply

The fact that the web.dev site itself has questionable semantics under the hood and a DOM outline with an inconsistent/incomplete hierarchy was the first red flag for me who is no means an expert in these things. Thank you for enumerating the other issues, I’ll be sharing this with my team!

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>