Diagnostic.css is a stylesheet which allows the user to test for common errors in a page's markup

  • By Karl Groves
  • Last update: Jun 20, 2022
  • Comments: 5


Diagnostic.css is a stylesheet which allows the user to test for common errors in a page's markup. Inspired by Eric Meyer's diagnostic CSS file, this one is intended to flesh out accessibility related issues on a page.


The goal of this stylesheet is to provide very quick, very accurate feedback. As a consequence, items that are too conservative and create "false positives" are likely to be eliminated from the sheet and won't be included in any merges.

How to use

If you're working with a site you own, add this (temporarily, of course) to your site to display the errors.

If you're checking work you don't have access to, use this as a user style.


Alternately, use the bookmarklet.js found in this repo. Create a bookmarklet in your browser and then click it when you're on a page you want to test.

User Script

NEW, as of 07-December 2013, there's a new file, diagnostic-css.user.js in this repo which can be used as a user script. This enables you to get the diagnostic CSS feedback without having to constantly activate the bookmarklet above. This is particularly useful for use case testing or user acceptance testing because you can simply activate this script and browse the screens you want to test.

If you have Greasemonkey installed on Firefox, open the diagnostic-css.user.js file with Firefox. This will install the script as a userscript. Download Greasemonkey at https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/

Note, as it is set-up now, this userscript is "on" for all websites. To turn this on for only certain sites, such as those you own, modify the @include directive in the script file. Alternately, you can enable/ disable the script within greasemonkey itself.

Make it better

This is an open repo. Contribute to it, add to the documentation, submit an issue, etc.

Change Log

07-December 2013: Added user script.

28-September 2013: Fixed a bad negation selector for area elements without alt attributes.

06-September 2013: Totally revamped the stylesheet. Added new selectors. Added generated content to show error information.

13-September 2013: Merged request from AWK to change overly conservative rule.

OH, the irony

I realize that CSS-generated content is not content. I've even posted about it: http://www.karlgroves.com/2013/08/26/css-generated-content-is-not-content/

This is intended to be a quick way for developers to get immediate feedback without requiring a tool. If anyone wishes to expand, build upon, or collaborate on this in a more accessible way, please get in touch!




  • 1

    "Deprecated Attributes - cannot be overridden by user styles" - but yes, they can?!

    I wonder about this line:


    I didn't check it myself, but a quick search on the web reveals e.g. this:

    CSS specificity and deprecated HTML attributes

    There it's stated that these attributes can be overridden by CSS.

    Who's right?

  • 2

    separate some of the accessibility-related items from the more general items

    For instance, under deprecated attributes is a selector that checks for the 'target' attribute. This is an accessibility concern that extends beyond the use of deprecated markup and should be called out separately

  • 3

    More diagnostic/error rules (html[lang], title, legend, [dir], meta refresh (!) and input[type="image"]) and a test file


    after forking your existing stylesheet, I added a few rules to detect and display:

    • lack of html[lang],
    • displaying title(s) at top of page, flagging duplicates and empty ones (forgot about title not in head),
    • legend not being the first element of a fieldset (and other element being the first child of the latter),
    • [dir] whether rtl or ltr,
    • displaying a <meta> refresh (!) (found the selector in Accessibility First step from Opquast/Temesis, credit is in the comments of the CSS)
    • input[type="image"] and empty alt attribute or lack of (no :before or :after with this element so it's hard to flag it in pure CSS. Maybe in the future with a base64-encoded background?)

    A few links to WCAG 2.0 Techniques are in the comment of some of the rules.

    I also added a test file for legends with a valid example and a bad one (I hope so). In this file, each select has a different kind of label; this is intended :)

    Feel free to tell me if this is or isn't the kind of CSS rules and display you'd like to see in diagnostic.css, I've an extensive list of ideas taken from the Accessiweb 2.2 checklist and other tools :)

    Best regards, Ph. Vayssière

  • 4

    Add warning-level check for silly use of roles

    Selector would be *[role="button"], *[role="heading"], *[role="link"], *[role="list"], *[role="radio"], *[role="textbox"]

    Depends on Issue #15

  • 5

    Check for ARIA Landmarks

    Some examples:

    Checking for role="main" /

    on #main...

    #main:not([role="main"]):not(main):after {
       content: 'error message';

    Checking for role="banner" on page-level header:

    body > header:not([role="banner"]), 
    #page-header:not([role="banner"]) {
       content: 'error message';

    You could do the same for contentinfo on the page footer, maybe?