8 ms·

The A11Y Project Checklist

128 points by divbzero 4y ago

tweetle_beetle 4y ago
The work of the project is great and I'm grateful for the tools they produce, which I have used. But bit surprised to see some of the low hanging fruit from their own list not being applied in the project's own site. Just a few things I spotted in couple of minutes: The colour contrast of the title section fails all tests. The title itself is so big that it requires scanning the full width of the monitor regardless of font scaling; and the introductory paragraph (and header navigation) is placed over the top of the title, obscuring it. I also thought uppercase text-transform was best avoided. The checkboxes themselves move when you open/close the details/summary blocks which is disorientating. You can't tab onto the citation links (maybe up for debate). I take this topic seriously, so this isn't just flippant. Unfortunately if you want others to take these things seriously too, you need to practice what you preach.
- savanaly 4y ago
  Agreed. Contrast with an accessibility website that actually practices what it preaches: https://webaim.org/ https://webaim.org/
- extra88 4y ago
  > The colour contrast of the title section fails all tests. It doesn't. The background color is --color-blue: #3b4bbf and the SVG's fill color is --color-blue-tint: #d4d8f2, a 5.1:1 contrast ratio. Having the top-level page titles replicated as such giant SVGs is probably overdoing it but the user also has the page title in the browser tab and the word "Checklist" underlined in the main navigation to locate themselves (the actual h1 heading for the page is visually hidden contains "Checklist." I didn't find a viewport size/shape that had the overlapping you're describing, maybe their design has a problem they didn't find and you could report it to them [0]. > I also thought uppercase text-transform was best avoided Do you mean on "Check your WCAG compliance?" Making all the text on a page or full sentences all uppercase can make it hard to read, I don't think you have to pretend `text-transform: uppercase` doesn't exist. It's definitely better to use the property to make text uppercase as a design choice vs. actually writing the text using all capital letters, at least some of the time browsers and assistive technologies can treat them differently. I think the A11y Project in particular tries to reach designers and developers who often think "accessibility" means making sites plain, boring, and/or ugly. Therefore, they've adopted a design that is more capital "D" Designed on their top-level pages; that may mean not making everything maximally accessible 100% of the time. Additionally, people will always disagree about design choices. [0] https://github.com/a11yproject/a11yproject.com/ https://github.com/a11yproject/a11yproject.com/
t-3 4y ago
How is A-11-y any more accessible a word than accessibility? The "replace-the-middle-with-numbers" shortening scheme makes absolutely no sense, is confusing for anyone that doesn't already know, and saving space is absolutely not an issue in this post-paper era. Just why? Who thought this was a good idea?
- mwcampbell 4y ago
  FWIW, at least one prominent accessibility advocate in the blind community agrees: https://mosen.org/make-accessibility-discussion-more-accessible-dont-use-the-a11y-hashtag/ https://mosen.org/make-accessibility-discussion-more-accessi...
- tsuujin 4y ago
  Who thought this was a good idea? Probably people who had to type “accessibility” out a dozen times a day. Also marketing minded people who know a memorable title keeps people thinking about the topic longer. Side note, numeronyms have been around for a long time. This isn’t something we just invented for a11y. Also side note: I personally love “a11y” because it makes me think of “ally”, which is what we would all be to people with special needs if we religiously adopted a11y.
  - bigwavedave 4y ago
    The voice in my head that narrates whatever I read pronounced it "ally" from the start- it didn't read it as "A-eleven-why" until someone mentioned it, so if nothing else it had the desired effect on me!
KaiserPro 4y ago
I worked at a large financial news site for a number of years. In that time they spent a lot of engineering time to make the site accessible (you can see the types of the problems that crop up here: https://twitter.com/financialtimes/status/1489637761598566402?lang=en-GB https://twitter.com/financialtimes/status/148963776159856640...) However I didn't know we had a team doing that. why? because they called themselves "a11y". I thought it was an analytics team, or and inside joke name. I would see a11y requests, commits and infra changes, but I didn't twig what it was for. I had seen the team lead talk about accessibility in meetings, and I knew that it was very close to their heart, they'd even given conference talks about it. It was only when the team lead changed roles, and I had a catchup with them and asked them what the team name meant. They looked at me and said "its like i8n, you know what that is, you fiddle with it all the time" When I looked blank they said: "you know changing locales and stuff" you mean in Internationalization? Then the penny dropped. a11y == accessibility. the irony of having the least accessible name, for improving accessibility.
- neltnerb 4y ago
  And a screen reader would have no idea how to parse it without a special case... I've seen stuff tagged with this a lot and every so often someone mentions this issue and I've yet to find an explanation other than if you already know about it it's easier to search for. I appreciate the advice nonetheless but it's just such an odd choice for making it discoverable.
  - ChadNauseam 4y ago
    Why would a screen reader have any more trouble with it than someone reading it normally? I usually read it as "ay-one-one-why" or "ally", is that how a screen reader would interpret it?
    - neltnerb 4y ago
      Right, it would read it as "ay-one-one-why". And if you're trying to dictate it, you'd have to say "ay-one-one-why". I don't want to distract from the main point, which is that you should make your websites accessible and that doing so mostly involves not letting some UI designer use a cool trick that lets them do some cute effect that has the side effect of breaking the experience when using accessibility tools. Because they're usually written by people without a need for accessibility tools they don't even notice what they're doing. This is extremely important educational work. And 'a11y' is less horizontal width, so someone who needs to zoom in really far to read text would probably appreciate it, or someone who can still type but doesn't do dictation has to hit fewer keys. But what other situation does it help with? It's jargon, You have to just kind of know that there are 11 characters between the 'a' and the 'y' in accessibility? If the goal is to educate people who don't need accessibility tools themselves it should not be a challenge for people who aren't in the know to find the information. I appreciate the effort and recognize that it caught on. I just don't get why, it seems like it is throwing a needless barrier in the way of the target audience finding the resources. I still try to follow the ideas presented, I just don't understand making it require jargon to find.
lgleason 4y ago
I've had to work on a11y efforts. One challenge I see is that some websites/apps are not overly usable for people that don't have disabilities. Also, many of the calls on what needs to happen or not are subjective when getting an audit and go far beyond this list guidelines. Then on top of that if you are big enough, or get in someones crosshairs, you face the threat of the DOJ making an example of your company based on a number of standards (beyond this checklist) that are nebulous.
- extra88 4y ago
  > if you are big enough, or get in someones crosshairs, you face the threat of the DOJ making an example of your company based on a number of standards (beyond this checklist) that are nebulous. Nonsense. This checklist relates all its items with WCAG criteria; basically all legal requirements directly cite WCAG or have requirements based on them. Even though meeting all WCAG criteria does not guarantee that every person in the world can use the content, no entity is going to get sued for that. Also, the checklist is preceded by "Does this checklist guarantee my site is accessible? No. However, addressing the issues called out in this checklist will help improve the experience for everyone who uses your site."
chrischen 4y ago
Is there an automatic scanner that reports problems like Google’s Lighthouse?
- extra88 4y ago
  Most accessibility problems require human review to identify. Google Lighthouse uses a subset of the checks included in axe-core. axe-core is a good resource for adding accessibility checks to e2e testing. The WAVE extension already mentioned is good for getting feedback about a page in the browser, the axe DeveTools extension is also good, the paid version can guide more manuals checks, simplifying the process.
- krono 4y ago
  It's a good thing you're looking for an automated solution, because with that attitude you're not going to find any accessibility problems on your own :P https://www.w3.org/WAI/ER/tools/ https://www.w3.org/WAI/ER/tools/
- Y-bar 4y ago
  I use https://wave.webaim.org/extension/ https://wave.webaim.org/extension/ with good results
- darekkay 4y ago
  I wrote Evaluatory [1] for this, which started mainly as an axe-core wrapper (which is what Lighthouse uses as well) with a visual results page. Now it contains more tools and checks as well. [1] https://darekkay.com/evaluatory/ https://darekkay.com/evaluatory/
  - thelittleone 4y ago
    Looks like a fit for a project I have. Is there a simple way to configure for authenticated pages?
    - darekkay 4y ago
      Basic Auth should work out-of-the-box, though I haven't tested it. If you need any advanced authentication, Playwright [0] - which I use for fetching the pages - shoud have you covered. You can pass any custom playwright options via `playwrightOptions` in the Evaluatory config file. [0] https://playwright.dev/ https://playwright.dev/
playpause 4y ago
This looks like a great resource. Human checklists are not perfect but they tend to be better than automated checks for this sort of thing. But there is a common form of accessibility guideline that I have a problem with, and this one illustrates it well: "Avoid using the autofocus attribute." The problem here is it quietly pits users with special accessibility needs against the rest - "Just don't use feature X." OK, but what should I do instead for the rest of my users who benefited from feature X? What if I'm making a search engine landing page and I want to automatically focus the input on page load (and automatically bring up their keyboard if touchscreen)? Is there some other approach that achieves the same UX as the autofocus attribute but without creating accessibility problems? According to MDN, "When autofocus is assigned, screen-readers 'teleport' their user to the form control without warning them beforehand." OK, but really? Why? Why don't they offer the user the option to not do that?
- extra88 4y ago
  Checklists are not a place for nuance. A search engine landing page is a place where using autofocus in the search field is perfectly appropriate; autofocusing a search field that's in the header of every page is not.
  - playpause 4y ago
    I agree, autofocusing a search field that's in the header of every page is not generally appropriate, but that's not specifically about accessibility. It would be annoying for anyone on a mobile device (keyboard pops up on every page), and the focus ring and/or blinking cursor would be distracting. What about cases where it is appropriate to autofocus the search input (as it's the primary action on the page) but where there also might (sometimes) be an important text notice above the search input? Sighted users would see the notice fine, while screenreader users would be 'teleported' (MDN's word) straight past it, missing the notice.
    - mwcampbell 4y ago
      I believe it's up to screen reader developers to come up with innovative ways of making the web as it currently exists more usable, rather than requiring the millions of websites out there to accommodate the technology's current limitations. In this case, perhaps screen readers need to somehow intelligently read nearby text when a control immediately receives focus on page load.
WaxedChewbacca 4y ago
nathias 4y ago
you can use the WAVE extension that will check things for you automatically
yellow_lead 4y ago
What an ugly design for such a page
- giraffe_lady 4y ago
  looks fucking awesome imo. It's an all-text page that someone clearly spent some time on the typography and layout for. Simple layout, easy to navigate, super fast. What are you looking for instead?
  - hallway_monitor 4y ago
    Looks fucking disgusting IMO. It's an all-text page that has been vomited on by a "designer" and is now unreadable. Text is great. This page is not accessible to me; honestly it feels like my eyes are being assaulted by this garish abomination.
  - wswope 4y ago
    (I typed this out before checking: rendering is just broken for latest FF on Win10. The color palette is entirely different from what's intended, and looks like a very crappy dark mode. The site looks much nicer in Edge. Edit: probably depends on your browser's preferred color scheme: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref....) Here are some specific design flaws. This is not exhaustive, and I'm trying to stick to the more objective issues: - On the title section, the "Check your WCAG compliance" text box with the same background color as the div behind it, placed above the massive "CHECKLIST" text, combined with the disjointed placement of the Table of Contents immediately makes the page look like it has some broken rendering going on. - Wildly inconsistent margins between different sections of content. Nothing is well-aligned on a grid between regions of the page. - The light grey <p> text on the grey background is low-contrast, and hard to read as a result. - The blue background of the <code> blocks is jarring, as it looks similar to selected/highlighted text. - Far, far too much padding and line spacing. Very little content fits into view at once on a 720p screen. It is one of the worst designed websites I've seen in a while.

128 points by divbzero 4y ago

The work of the project is great and I'm grateful for the tools they produce, which I have used. But bit surprised to see some of the low hanging fruit from their own list not being applied in the project's own site. Just a few things I spotted in couple of minutes: The colour contrast of the title section fails all tests. The title itself is so big that it requires scanning the full width of the monitor regardless of font scaling; and the introductory paragraph (and header navigation) is placed over the top of the title, obscuring it. I also thought uppercase text-transform was best avoided. The checkboxes themselves move when you open/close the details/summary blocks which is disorientating. You can't tab onto the citation links (maybe up for debate). I take this topic seriously, so this isn't just flippant. Unfortunately if you want others to take these things seriously too, you need to practice what you preach.

savanaly 4y ago
Agreed. Contrast with an accessibility website that actually practices what it preaches: https://webaim.org/ https://webaim.org/
extra88 4y ago
> The colour contrast of the title section fails all tests. It doesn't. The background color is --color-blue: #3b4bbf and the SVG's fill color is --color-blue-tint: #d4d8f2, a 5.1:1 contrast ratio. Having the top-level page titles replicated as such giant SVGs is probably overdoing it but the user also has the page title in the browser tab and the word "Checklist" underlined in the main navigation to locate themselves (the actual h1 heading for the page is visually hidden contains "Checklist." I didn't find a viewport size/shape that had the overlapping you're describing, maybe their design has a problem they didn't find and you could report it to them [0]. > I also thought uppercase text-transform was best avoided Do you mean on "Check your WCAG compliance?" Making all the text on a page or full sentences all uppercase can make it hard to read, I don't think you have to pretend `text-transform: uppercase` doesn't exist. It's definitely better to use the property to make text uppercase as a design choice vs. actually writing the text using all capital letters, at least some of the time browsers and assistive technologies can treat them differently. I think the A11y Project in particular tries to reach designers and developers who often think "accessibility" means making sites plain, boring, and/or ugly. Therefore, they've adopted a design that is more capital "D" Designed on their top-level pages; that may mean not making everything maximally accessible 100% of the time. Additionally, people will always disagree about design choices. [0] https://github.com/a11yproject/a11yproject.com/ https://github.com/a11yproject/a11yproject.com/

t-3 4y ago

How is A-11-y any more accessible a word than accessibility? The "replace-the-middle-with-numbers" shortening scheme makes absolutely no sense, is confusing for anyone that doesn't already know, and saving space is absolutely not an issue in this post-paper era. Just why? Who thought this was a good idea?

mwcampbell 4y ago
FWIW, at least one prominent accessibility advocate in the blind community agrees: https://mosen.org/make-accessibility-discussion-more-accessible-dont-use-the-a11y-hashtag/ https://mosen.org/make-accessibility-discussion-more-accessi...
tsuujin 4y ago
Who thought this was a good idea? Probably people who had to type “accessibility” out a dozen times a day. Also marketing minded people who know a memorable title keeps people thinking about the topic longer. Side note, numeronyms have been around for a long time. This isn’t something we just invented for a11y. Also side note: I personally love “a11y” because it makes me think of “ally”, which is what we would all be to people with special needs if we religiously adopted a11y.
- bigwavedave 4y ago
  The voice in my head that narrates whatever I read pronounced it "ally" from the start- it didn't read it as "A-eleven-why" until someone mentioned it, so if nothing else it had the desired effect on me!

KaiserPro 4y ago

I worked at a large financial news site for a number of years. In that time they spent a lot of engineering time to make the site accessible (you can see the types of the problems that crop up here: https://twitter.com/financialtimes/status/1489637761598566402?lang=en-GB https://twitter.com/financialtimes/status/148963776159856640...) However I didn't know we had a team doing that. why? because they called themselves "a11y". I thought it was an analytics team, or and inside joke name. I would see a11y requests, commits and infra changes, but I didn't twig what it was for. I had seen the team lead talk about accessibility in meetings, and I knew that it was very close to their heart, they'd even given conference talks about it. It was only when the team lead changed roles, and I had a catchup with them and asked them what the team name meant. They looked at me and said "its like i8n, you know what that is, you fiddle with it all the time" When I looked blank they said: "you know changing locales and stuff" you mean in Internationalization? Then the penny dropped. a11y == accessibility. the irony of having the least accessible name, for improving accessibility.

neltnerb 4y ago
And a screen reader would have no idea how to parse it without a special case... I've seen stuff tagged with this a lot and every so often someone mentions this issue and I've yet to find an explanation other than if you already know about it it's easier to search for. I appreciate the advice nonetheless but it's just such an odd choice for making it discoverable.
- ChadNauseam 4y ago
  Why would a screen reader have any more trouble with it than someone reading it normally? I usually read it as "ay-one-one-why" or "ally", is that how a screen reader would interpret it?
  - neltnerb 4y ago
    Right, it would read it as "ay-one-one-why". And if you're trying to dictate it, you'd have to say "ay-one-one-why". I don't want to distract from the main point, which is that you should make your websites accessible and that doing so mostly involves not letting some UI designer use a cool trick that lets them do some cute effect that has the side effect of breaking the experience when using accessibility tools. Because they're usually written by people without a need for accessibility tools they don't even notice what they're doing. This is extremely important educational work. And 'a11y' is less horizontal width, so someone who needs to zoom in really far to read text would probably appreciate it, or someone who can still type but doesn't do dictation has to hit fewer keys. But what other situation does it help with? It's jargon, You have to just kind of know that there are 11 characters between the 'a' and the 'y' in accessibility? If the goal is to educate people who don't need accessibility tools themselves it should not be a challenge for people who aren't in the know to find the information. I appreciate the effort and recognize that it caught on. I just don't get why, it seems like it is throwing a needless barrier in the way of the target audience finding the resources. I still try to follow the ideas presented, I just don't understand making it require jargon to find.

lgleason 4y ago

I've had to work on a11y efforts. One challenge I see is that some websites/apps are not overly usable for people that don't have disabilities. Also, many of the calls on what needs to happen or not are subjective when getting an audit and go far beyond this list guidelines. Then on top of that if you are big enough, or get in someones crosshairs, you face the threat of the DOJ making an example of your company based on a number of standards (beyond this checklist) that are nebulous.

extra88 4y ago
> if you are big enough, or get in someones crosshairs, you face the threat of the DOJ making an example of your company based on a number of standards (beyond this checklist) that are nebulous. Nonsense. This checklist relates all its items with WCAG criteria; basically all legal requirements directly cite WCAG or have requirements based on them. Even though meeting all WCAG criteria does not guarantee that every person in the world can use the content, no entity is going to get sued for that. Also, the checklist is preceded by "Does this checklist guarantee my site is accessible? No. However, addressing the issues called out in this checklist will help improve the experience for everyone who uses your site."

chrischen 4y ago

Is there an automatic scanner that reports problems like Google’s Lighthouse?

extra88 4y ago
Most accessibility problems require human review to identify. Google Lighthouse uses a subset of the checks included in axe-core. axe-core is a good resource for adding accessibility checks to e2e testing. The WAVE extension already mentioned is good for getting feedback about a page in the browser, the axe DeveTools extension is also good, the paid version can guide more manuals checks, simplifying the process.
krono 4y ago
It's a good thing you're looking for an automated solution, because with that attitude you're not going to find any accessibility problems on your own :P https://www.w3.org/WAI/ER/tools/ https://www.w3.org/WAI/ER/tools/
Y-bar 4y ago
I use https://wave.webaim.org/extension/ https://wave.webaim.org/extension/ with good results
darekkay 4y ago
I wrote Evaluatory [1] for this, which started mainly as an axe-core wrapper (which is what Lighthouse uses as well) with a visual results page. Now it contains more tools and checks as well. [1] https://darekkay.com/evaluatory/ https://darekkay.com/evaluatory/
- thelittleone 4y ago
  Looks like a fit for a project I have. Is there a simple way to configure for authenticated pages?
  - darekkay 4y ago
    Basic Auth should work out-of-the-box, though I haven't tested it. If you need any advanced authentication, Playwright [0] - which I use for fetching the pages - shoud have you covered. You can pass any custom playwright options via `playwrightOptions` in the Evaluatory config file. [0] https://playwright.dev/ https://playwright.dev/

playpause 4y ago

This looks like a great resource. Human checklists are not perfect but they tend to be better than automated checks for this sort of thing. But there is a common form of accessibility guideline that I have a problem with, and this one illustrates it well: "Avoid using the autofocus attribute." The problem here is it quietly pits users with special accessibility needs against the rest - "Just don't use feature X." OK, but what should I do instead for the rest of my users who benefited from feature X? What if I'm making a search engine landing page and I want to automatically focus the input on page load (and automatically bring up their keyboard if touchscreen)? Is there some other approach that achieves the same UX as the autofocus attribute but without creating accessibility problems? According to MDN, "When autofocus is assigned, screen-readers 'teleport' their user to the form control without warning them beforehand." OK, but really? Why? Why don't they offer the user the option to not do that?

extra88 4y ago
Checklists are not a place for nuance. A search engine landing page is a place where using autofocus in the search field is perfectly appropriate; autofocusing a search field that's in the header of every page is not.
- playpause 4y ago
  I agree, autofocusing a search field that's in the header of every page is not generally appropriate, but that's not specifically about accessibility. It would be annoying for anyone on a mobile device (keyboard pops up on every page), and the focus ring and/or blinking cursor would be distracting. What about cases where it is appropriate to autofocus the search input (as it's the primary action on the page) but where there also might (sometimes) be an important text notice above the search input? Sighted users would see the notice fine, while screenreader users would be 'teleported' (MDN's word) straight past it, missing the notice.
  - mwcampbell 4y ago
    I believe it's up to screen reader developers to come up with innovative ways of making the web as it currently exists more usable, rather than requiring the millions of websites out there to accommodate the technology's current limitations. In this case, perhaps screen readers need to somehow intelligently read nearby text when a control immediately receives focus on page load.

WaxedChewbacca 4y ago

nathias 4y ago

you can use the WAVE extension that will check things for you automatically

yellow_lead 4y ago

What an ugly design for such a page

giraffe_lady 4y ago
looks fucking awesome imo. It's an all-text page that someone clearly spent some time on the typography and layout for. Simple layout, easy to navigate, super fast. What are you looking for instead?
- hallway_monitor 4y ago
  Looks fucking disgusting IMO. It's an all-text page that has been vomited on by a "designer" and is now unreadable. Text is great. This page is not accessible to me; honestly it feels like my eyes are being assaulted by this garish abomination.
- wswope 4y ago
  (I typed this out before checking: rendering is just broken for latest FF on Win10. The color palette is entirely different from what's intended, and looks like a very crappy dark mode. The site looks much nicer in Edge. Edit: probably depends on your browser's preferred color scheme: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref....) Here are some specific design flaws. This is not exhaustive, and I'm trying to stick to the more objective issues: - On the title section, the "Check your WCAG compliance" text box with the same background color as the div behind it, placed above the massive "CHECKLIST" text, combined with the disjointed placement of the Table of Contents immediately makes the page look like it has some broken rendering going on. - Wildly inconsistent margins between different sections of content. Nothing is well-aligned on a grid between regions of the page. - The light grey <p> text on the grey background is low-contrast, and hard to read as a result. - The blue background of the <code> blocks is jarring, as it looks similar to selected/highlighted text. - Far, far too much padding and line spacing. Very little content fits into view at once on a 720p screen. It is one of the worst designed websites I've seen in a while.