[HN Gopher] The A11Y Project Checklist
___________________________________________________________________
The A11Y Project Checklist
Author : divbzero
Score : 122 points
Date : 2022-05-11 08:18 UTC (14 hours ago)
(HTM) web link (www.a11yproject.com)
(TXT) w3m dump (www.a11yproject.com)
| chrischen wrote:
| Is there an automatic scanner that reports problems like Google's
| Lighthouse?
| Y-bar wrote:
| I use https://wave.webaim.org/extension/ with good results
| krono wrote:
| 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/
| extra88 wrote:
| 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.
| darekkay wrote:
| 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/
| thelittleone wrote:
| Looks like a fit for a project I have. Is there a simple way
| to configure for authenticated pages?
| darekkay wrote:
| 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/
| tweetle_beetle wrote:
| 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.
| extra88 wrote:
| > 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/
| savanaly wrote:
| Agreed. Contrast with an accessibility website that actually
| practices what it preaches: https://webaim.org/
| yellow_lead wrote:
| What an ugly design for such a page
| giraffe_lady wrote:
| 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 wrote:
| 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.
| lgleason wrote:
| 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 wrote:
| > 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."
| playpause wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| extra88 wrote:
| No. Browsers already parse the page to produce an
| accessibility tree that's provided through the operating
| system's accessibility API. Screen readers attempting to
| supplement what's provided through that API by re-parsing
| the page should be a last resort and is bound to be
| error-prone.
|
| Designers and developers need to learn that what they
| make will be, and should be, experienced in ways
| different than how they do. Content is experienced
| linearly, not always in two dimensions, and semantics can
| make programmatically explicit what is only implied
| visually (like heading text being bigger and bolder).
|
| The prevalence of smartphones and responsive design have
| helped somewhat to expand people's understanding of how
| using digital experiences can vary. There's a lot more
| that can be learned.
|
| Aside from not using autofocus on the input field at all,
| another existing option is to programmatically associate
| the preceding block of text by giving the block a unique
| id and referencing it from the input using an aria-
| describedby attribute; after a screen reader reads the
| input's accessible name, it will read the associated
| description.
| rendall wrote:
| > _while screenreader users would be 'teleported' (MDN's
| word) straight past it, missing the notice._
|
| Autofocus in that case seems like reasonable and expected
| behavior. Isn't it up to the tools (e.g. screen reader,
| etc) to accommodate the expected behavior, rather than for
| the reasonable and expected behavior to change?
| extra88 wrote:
| No. It is reasonable and expected that some users
| experience page content linearly so designers and
| developers have to create experiences that takes that
| into account. That includes not skipping important
| content. If it's important, don't skip it. If it's not
| important, maybe it's okay to skip it but there should be
| means for users to explore and discover what's on the
| page (like give the preceding block of text a heading
| that indicates what that section of content is about).
| rendall wrote:
| Hmm. "All users should experience the page linearly
| because some do" is not really an argument that works.
| extra88 wrote:
| A sighted user with a cursor or touchscreen can be as
| non-linear as the size of the viewport and the layout
| allows.
|
| All designers should design the linear experience as well
| as the non-linear experience because the linear is all
| some users will have. Responsive design is a move in that
| direction, a smartphone portrait display is much narrower
| than a laptop display so the content tends to be in a
| more linear layout. Experiences through voice assistants
| are also linear.
| Diggsey wrote:
| I agree with the comment, but:
|
| > Why? Why don't they offer the user the option to not do that?
|
| A screen-reader doesn't replace the browser - it just responds
| to changes in focus by reading out a description of the
| currently focused item. It should be the browser that offers an
| option to disable autofocus. Firefox does seem to have an
| option in about:config called "browser.autofocus" which I
| assume does this exact thing.
| mwcampbell wrote:
| The screen reader could still choose to ignore the automatic
| focus and read the whole page instead.
| wwweston wrote:
| I have no particular disability at the moment and I'm
| struggling to think of anything that autofocus adds to my
| browsing experience and not struggling to think of times it's
| annoyed me.
| hallway_monitor wrote:
| On the other hand, I am endlessly annoyed when e.g. Ebay /
| Amazon do not auto focus the search box on page load.
| Anything else I'm going to click and probably 50% of the time
| I want to search. Just auto-focus please.
| KaiserPro wrote:
| 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/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.
| 199X wrote:
| Something similar happens nowadays in Spanish, where people use
| an X as a gender-neutral suffix. Ruining the experience for the
| visually impaired users that use screen readers. The irony of
| being 'inclusive' with the non-binary while being exclusive
| with the visually impaired
| gherkinnn wrote:
| How much of that is non-Spanish speaking Americans imposing
| American ideas on the world?
| thewebcount wrote:
| Thank you for saying this! I see stuff like this a lot here on
| HN and I almost never know what it means. A16z? Fuck if I know
| what that is.
|
| It reminds me of the terrible sports video game naming -
| NBA2k22. I get Y2K was fewer characters than fully typing out
| "year 2000," so it kind of made sense. But 2k22 is the same
| number of characters as "2022". What is being saved here? It
| just creates confusion without adding anything useful.
| KaiserPro wrote:
| I'm so bloody glad I'm not the only one!
| noisem4ker wrote:
| 2K Games is the publisher.
| corndoge wrote:
| It's called 2k in common parlance now, doesn't make sense
| from a branding perspective to change it
| neltnerb wrote:
| 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 wrote:
| 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 wrote:
| 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.
| extra88 wrote:
| It's good advice for _any_ abbreviation to define or provide
| the expanded form the first time it 's used; The A11y Project
| does this in the top heading on its home page, "a11y stands for
| accessibility." It might be helpful for the project to include
| that explanation on every page, even if it's just in the
| footer.
|
| "a11y" is useful as a hashtag, is shorter and easier to spell.
| A11y is a good search term; content containing "a11y" will be
| about digital accessibility. Content containing "accessibility"
| could be about DNS issues, account authorization, or a number
| of other topics even before search "helpfully" expands the
| search to include "accessible," "access," and other terms.
| WaxedChewbacca wrote:
| nathias wrote:
| you can use the WAVE extension that will check things for you
| automatically
| t-3 wrote:
| 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 wrote:
| FWIW, at least one prominent accessibility advocate in the
| blind community agrees: https://mosen.org/make-accessibility-
| discussion-more-accessi...
| tsuujin wrote:
| 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 wrote:
| 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!
___________________________________________________________________
(page generated 2022-05-11 23:02 UTC)