a11yproject / a11yproject.com

The A11Y Project is a community-driven effort to make digital accessibility easier.
https://a11yproject.com
Apache License 2.0
3.73k stars 556 forks source link

Content: Checklist WCAG references should be changed for better accuracy #1277

Open mxmason opened 3 years ago

mxmason commented 3 years ago

Summary

The checklist currently makes incorrect references to specific WCAG criteria. The community should review the checklist content for better accuracy

Suggested edits courtesy of Scott O'Hara: >> Make sure that button, a, and label element content is unique and descriptive. > this is likely more a 2.4.4 issue for links (possibly 2.4.9 depending on context) and a 2.4.6 issue for labels... possibly buttons. It's a bit dicey putting these all together, but the point being that 1.3.1 doesn't really apply here. I'm not sure exactly what you want to do here, but I suggest at the very least removing the SC if you can't cite multiple SCs. >> Use landmark elements to indicate important content regions. > This would be a 1.3.1 issue. 4.1.2 is more about interactive content >> Avoid using the autofocus attribute. > Generally agree with this, but arguable if this would be a 2.4.3 issue. Sometimes using autofocus is exactly what you should do. Might be worth at least stating this is something to watch out for, rather than how this presently reads (to me) that it's an autofail. >> Remove title attribute tooltips. > This is arguably more of a 2.1.1 keyboard issue as - if the content is actually important - would generally be inaccessible to keyboard only users. since title is generally exposed to AT, 4.1.2 doesn't really hold true here. >> Check to see that keyboard focus order matches the visual layout. > 1.3.2 may not apply here as content doesn't necessarily need to match visual focus order. 2.4.3 may be more appropriate to cite. >> headings > All checklist items in the headings section incorrectly cite 2.4.6. 2.4.6 is about the quality of heading text, but has nothing to do with whether the text is properly exposed as a heading. These would all be 1.3.1/best practice issues. >> Use the th element for table headers (with appropriate scope attributes). > Unsure why this is cited as a 4.1.1 issue. Seems it should be a 1.3.1 >> Use the caption element to provide a title for the table. > Again, not a 2.4.6 unless there is a already implemented which has crummy text. >> All inputs in a form are associated with a corresponding label element. > Not a 3.2.2 issue. Typo for 3.3.2? >> Associate input error messaging with the input it corresponds to. > Should be 1.3.1 and/or 4.1.2. >> Ensure that media controls use appropriate markup. > Probably should be 4.1.2 since that's about interactive controls >> Confirm that transcripts are available. > Technically yes, audio content is 1.1.1. But alternatives to audio content would generally be cited under 1.2.3 >> Check your content in specialized browsing modes. > Would generally point to this as a strongly recommended best practice, not a wcag failure, particularly not this one. >> Remove horizontal scrolling. > would qualify some content - e.g., tables, maps, large graphs - are totally fine to have bi-directional scrolling. dont' want to make people think they have to negate table semantics and then potentially wind up with other wcag failures (e.g., 1.3.2) when content no longer makes sense in the reading order.
aguscha333 commented 3 years ago

Will start working on this now

aguscha333 commented 3 years ago

Quoting from the suggestions: So, here's the issues that jumped out at me when reviewing:

Make sure that button, a, and label element content is unique and descriptive.

this is likely more a 2.4.4 issue for links (possibly 2.4.9 depending on context) and a 2.4.6 issue for labels... possibly buttons. It's a bit dicey putting these all together, but the point being that 1.3.1 doesn't really apply here. I'm not sure exactly what you want to do here, but I suggest at the very least removing the SC if you can't cite multiple SCs.


What should I do with this? remove it as it is suggested? we do not currently support having multiple SCs.

scottaohara commented 3 years ago

i'd personally separate these out. labels / buttons could remain together under a 2.4.6 "make sure labels (which does not necessarily mean <label>s) are unique and descriptive to their purpose"

and then links could be separate checklist item like (reword as you see fit): "ensure that link content is descriptive and understandable in context" pointing to 2.4.4