Just a quick thought I wanted to raise for discussion.
We have to think about accessibility a lot, especially for frontend web dev. We often have requirements around certain levels of accessibility to reach, or at least it’s good practice to.
However, in practice I’m not sure how much we actually test for, or how much access we have to tools such as screenreaders. At least, as far as I know, we don’t generally do any kind of automated a11y linting/testing. A11y issues can easily slip through the cracks. And speaking for myself, I think there’s a lot of a11y considerations I’m not aware of.
What do you think? What can we do to support improved a11y practices? Automated a11y linting/testing pipelines? Should we take training? Is it worth spending time/money to set up screenreaders (either locally or some kind of shared environment; screenreaders can be expensive)? What is your experience?
Ticket: no ticket yet; not sure where to put this. I’m thinking about this as part of BB-11069.
As part of becoming a core contributor you have to tale a11y training, or at least had to back when I was added. If a project has a11y aspects I generally test on Linux with orca, so there is no expense.
Generally Paragon components are designed to be accessible, so if you’re just using Paragon for interactive components you should be well set. However, sometimes we do write custom components where we definitely should be doing a11y testing. Checking for a11y is part of a reviewers job, though I do think we often miss this aspect of the review.
The a11y course I did was quite useful so I do think everyone should probably do it if they haven’t already.
@kshitij - I would love to have an a11y training course; the one you took belonged to edX and they didn’t share it with us, so it’s actually not something we have available to CCs (and haven’t since 2021). I haven’t had the bandwidth or budget to work on this further, but it’s a good reminder as something to explore.
oxlint and eslint have some decent a11y lints that I would recommend using in general. However, I had to turn them off in the Authoring MFE for now because we’ve never had them on and the existing code has a lot of violations . I’d definitely recommend setting them up for new projects.
Testing with a screenreader is great, but it has a fairly steep learning curve. Two things that are easier which can get you some of the way there are:
Test the UI without a mouse, and make sure everything is keyboard-operable. (No special training or software required!)
Ensure your test suite uses accessible queries (i.e. use getByRole with an ARIA role and name, or use getByLabelText for pretty much everything, and avoid getByTestId entirely). This forces you to make sure your major UI elements have correct a11y annotations.
Yep I have tried Orca before, but not with great success - it’s complex, many keybinds and config. I would love the opportunity sometime to have a ticket to block time just for learning and configuring it.
Agreed. I think we can go a fair way by defining what checking for accessibility should cover. I generally do spot checks when I see things like complex UI elements or custom behaviour, but I’m not always sure what to look for. As @braden mentioned, testing with keyboard only is quick and simple, and I usually will do that, and look over the code to check for labels, aria-*, etc., but I don’t really know the scope, or best practices for a11y.
These are great, thanks!
I would love to see a set of guidelines put together for how we recommend setting up our repos, code, testing, etc. for a11y.
In fact, and this is a larger topic, it would be cool to have some sort of “repository health” guidelines/indicator , and expanded guidelines for manual reviewing/testing. This could cover things like checking rendered markdown/rst text, configuring Renovate, test coverage, a11y levels, etc. etc. I think we’re close to being able to do this.
. I’d definitely recommend setting them up for new projects.