henrycatalinismith
commented
2 years ago Oh hey I just now found https://github.com/zetkin/app.zetkin.org/issues/254! If you'd like, that's something I could help with. It can be nice to begin with a high-level view of what the issues are, in case there's opportunities to make small code changes that fix lots of things! In this case, for example, there are actually lots of these lighten() calls affecting lots of other text, so maybe a more holistic fix could be more appropriate?
I find that if I put a bit of love into it then It's quite satisfying work to put together a comprehensive set of these issues, like with steps to reproduce, little screencasts showcasing the screen reader interactions, recommended fixes, exact WCAG success criteria and so on. BTW it is true that Axe is excellent for automated auditing but the prevailing wisdom in the accessibility community is that automated audits can detect about 30% of issues. I'd absolutely love to help you get closer to a 100% picture through manual testing (and hopefully then see about hitting you with some PRs fixing it all!).
If you're interested maybe we can chat on Slack about scope, but to give a rough idea I'd expect to be able to throw between 30 and 60 minutes per day at this, file between 2 and 8 issues per day, and probably find between 50 and 200 total. I'd hope to be finished auditing and started fixing by Christmas if nothing comes up at home to take away my little window of focus time!
Here's a little sample issue that'd probably belong in zetkin-common.
User menu inaccessible to screen reader users and sighted keyboard-only users
Steps to reproduce
- Log in
- Attempt to focus the user menu with the tab key
- Enable your screen reader
- Focus the user menu
Expected outcome
The user menu should be keyboard operable as per WCAG success criterion 2.1.1.
The role and value of the user menu should be programmatically determinable as per WCAG success criterion 4.1.2.
Actual outcome
The user menu isn't keyboard operable as it's not possible to move keyboard focus onto it using the the tab key. In the following GIF, the tab keypress when the logo is focused should focus the user menu. Instead focus skips over it to the signup link.
In a screen reader, the user menu's role and value are ambiguous. In the following GIF, when the screen reader's focus arrives on the user menu, you would normally expect it to announce it as a button with a collapsed menu popup, but instead it's announced as plain text.
Recommendation
- Use a
<button>element instead of a<div>for the clickable element so that it'll be able to receive keyboard focus by default and will be announced as a button by screen readers. - Add
aria-haspopup="menu"to the button so that screen readers announce that it controls a popup menu. - Add an
aria-expandedattribute to the button with a value oftrueorfalsedepending on the current state of the menu so that the state of the menu isn't only available visually. - Add an
aria-labelto the button with something along the lines of${fullName} user menuto clarify what the menu is for, since some of its purpose is otherwise only represented visually via its top right position and the arrow icon adjacent to the name.
richardolsson
Hey there! I've just recently started using zetkin and got excited to contribute some accessibility improvements to it. Here's a nice simple one to see how I get on!
The
lighten()call here is reducing the contrast of the signup form input field labels to the point where people with low vision will struggle to read them. It's setting them to#999999, which has a contrast ratio of 2.86 against the white background. Removing thelighten()call changes it to#5C5C5C, which gives a nice big 6.69 contrast ratio!I've been doing some poking around and have noticed you're all super focused on the Generation 3 work right now so maybe this is outside your priorities for the moment and I'd understand that! But if you have time to take a look then this kind of small change would make a big difference for potential activists who have limited vision!