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.

Update: 24 July 2024

Stéphane Deschamps discovered that the browser support list for features promoted on Web.dev doesn’t actually provide the browser name anywhere. Pat confirmed it relies on CSS generated content of a background SVG. So filed The browser support list on web.dev does not include browser name. I recommended they use an <img> with good alt text.

Update: 4 September 2024

Thomas Steiner fixed the issue Stéphane identified, though he had to deal with me a lot (which, you know, ugh for that guy). So kudos to a good fix and responsiveness from Google.

On the other hand, that inaccessible tool-tip post by that solo writer I mentioned is not only still unaddressed, but that solo writer has decided to use draft standards to build a series of Chrome-only (and I quote) accessible popovers (which he calls overlays). I’m disappointed his effort went into these instead of fixing the long-broken one, so I left a comment on one of the videos. I am imperfect; I get that.

The comment…

Unsurprisingly as of 7 September the comment has not been approved, or was approved and hidden, or however they do it so nobody sees it but the count of comments still goes up.

I appreciate this showcases features coming to the web platform, but that means it won’t be viable for most organizations for a while.

In the meantime, can you take some of the effort you are putting into promoting this video and fix the existing tool-tip guidance you wrote two years ago? It still encodes WCAG failures (legal risk for those who use it and barriers for users) even after detailed feedback.

Ref: https://issuetracker.google.com/u/l/issues/298296173

Assume This Applies to Developer.Chrome.com

Over at the Chrome developer site, Scroll Snap Events demonstrates that the same technology, processes, and people that created all the issues I outlined above are just as active there.

I have always argued that Google’s refusal to underline links in runs of text is a problem. But when it does it for special cases, it still finds a way to make them do weird stuff, like dance, or mildly clip preceding text, or otherwise making them visually ineffectual. The posts still seem to rely on autoplaying looping videos with the video player controls removed, regardless of all the motion and flashing and WCAG violating. But the author(s) still promote standards-track yet Chrome-specific features that don’t work with a keyboard and lie to a screen reader. Even when you strip away all the custom code, the underlying pattern is a voice control nightmare and unintentional self-parody of the phone number UI meme.

Don’t use Developer.Chrome.com for accessibility info.

4 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!

Reply

Thank you for posting this, they offer a web accessibility course that I was considering and am now going to examine closer before recommending to other staff. We reference examples from component/pattern libraries and organizational knowledge repositories in our accessibility remediation often, and this shows its namesake lends it more credibility than it should. I am always on the lookout for accessible development libraries!

In response to Rae. Reply

Rae, one note I made above about the accessibility course: This excludes the dedicated accessibility training material, which I have not reviewed. The person who worked on it as an accessibility practitioner, versus the other content where someone claims the knowledge they clearly don’t have.

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>