Closed czosel closed 1 year ago
Another thought on this: it might also be worth refactoring to place inputs outside of labels, and use for
attributes. Screenreaders often perform better with this explicit style.
Thanks for your hint @jacob-financeit! I'll have refresh my web a11y knowhow a little to implement this with confidence, so any hints and contributions are more than welcome :blush:
Sorry, I was away for a bit. I think you can use Ember.guidFor() to make sure the label is associated with the right input
Hi @jacob-financeit, thanks again for you input. I realized that most of our form components are already using the for
attribute instead of wrapped labels, but they were missing the corresponding id
attribute. I created #51 with a quick fix for selects and simple input fields, but obviously that's just a start.
Using for
with radios or checkboxes seems to break the positioning when using bootstrap, and I also couldn't find any clear evidence that the wrapping is really bad for a11y (see e.g. this thread on SO). Do you know more on that?
No, that's why I phrased it as a 'might'... it's more explicit, and more normative, which usually helps screenreaders (and has been good for i.e. specific versions of NVDA in the past), but it's not a totally unambiguous thing. (That's also why I haven't devoted work time to it yet, because there are bigger / easier wins in other areas of my current project.)
For instance, one thing our QA pointed out is that validation messages are not read by i.e. VoiceOver. I am looking at making them ARIA live regions, so an update to a validation message will trigger it to be vocalized.
Alright, that makes sense. Proper id
attributes on all form elements is probably one of these quick wins - hopefully we can make some progress on this soon.
:tada: This issue has been resolved in version 6.2.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
We should include aria tags (like
aria-describedby
andaria-invalid
).