Skip to content

Latest commit

 

History

History
61 lines (48 loc) · 3.38 KB

README.md

File metadata and controls

61 lines (48 loc) · 3.38 KB
Raw

ember-a11y-roadmap

A Potential Roadmap for all things a11y in ember.js.

First, if you are not familiar with digital accessibility, please reference the conversation prep document first. You will likely be ill-equipped to think about the problem space without some introduction to the topic.

If you wish to contribute to this repository, PRs are welcome.

Low-effort changes

These are low-effort changes that would immediately improve the default conformance of new Ember applications, and demonstrate commitment to accessibility in EmberJS. All of the changes proposed may need iteration toward a long-term solution.

  • Add OOB support for page titles (should be unique per page as per WCAG 2.4.2- Page Titled). Similar is provided by ember-page-title.
  • Add default language attribute on the <html> element - basic documentation
  • Add aria-label, aria-labelledby, and aria-describedby attributes to the ...attributes exceptions (like class) - proposed draft RFC
  • Release an official framework statement regarding A11y in Ember.js
  • Publishing a "roadmap" or "intent to improve" list (along with an invitation to contribute)

Long-term changes

After some discussion, these things need a larger effort refactor, and accessibility should be part of that re-design:

  • Ember Router (and ensure support for assistive tech)
  • refactor the way the ...attributes feature works
  • create a locale-aware start to Ember apps?

Other useful improvements

  • focus management
  • keyboard navigation
  • semantic test helpers (improves code in general but could specifically be used to better test for accessibility conformance)
  • A11y in the guides
  • component patterns for accessible components
  • linting
  • ember language server support

Innovation Opportunities

Right now, only about 30% of accessibility issues can be automatically tested. We have the opportunity to improve that through innovative tooling.

RFCs

Existing

Research/write

  • vocalizing support for assistive technology (screen readers, specifically) in the same way we list browser support
  • dialogs/modals (parent window inert, focus management) [RFC Research]
  • keyboard nav
  • focus management

Documentation

Addons

ui addon with a11y-first approach