Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve a11y #48

Closed
czosel opened this issue Jul 12, 2017 · 7 comments · Fixed by #881
Closed

Improve a11y #48

czosel opened this issue Jul 12, 2017 · 7 comments · Fixed by #881

Comments

@czosel
Copy link
Contributor

czosel commented Jul 12, 2017

We should include aria tags (like aria-describedby and aria-invalid).

@jacob-financeit
Copy link
Contributor

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.

@czosel
Copy link
Contributor Author

czosel commented Jul 14, 2017

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 😊

@jacob-financeit
Copy link
Contributor

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

@czosel
Copy link
Contributor Author

czosel commented Jul 25, 2017

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?

@jacob-financeit
Copy link
Contributor

jacob-financeit commented Jul 25, 2017

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.

@czosel
Copy link
Contributor Author

czosel commented Jul 25, 2017

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.

@anehx anehx closed this as completed in #881 Nov 9, 2022
adfinisbot pushed a commit that referenced this issue Feb 23, 2023
# [6.2.0](v6.1.2...v6.2.0) (2023-02-23)

### Bug Fixes

* scroll error into view with nested key names ([#904](#904)) ([5c192a5](5c192a5))

### Features

* **a11y:** add aria invalid and describedby attributes on validation ([6e16a51](6e16a51)), closes [#48](#48)
@adfinisbot
Copy link
Member

🎉 This issue has been resolved in version 6.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants