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.
