(Draft)
There are two levels of accessibility features we aim to provide with V3:
- Making the editor usable by people with disabilities.
- Ensuring that accessibility features can be introduced in the contents produced with the editor, guaranteeing and enforcing the minimum accessibility level in the contents.
Standards
The first and most practical way to ensure accessibility in both the above aspects is by following the rules and requirements defined by the common standard available for web applications.
We have chosen two of the most notable standards as those we'll be working to be compliant to:
- The WAI, published by the W3C, which actually comprehends a number of standards and guidelines that interest our project: Web Content Accessibility Guidelines (WCAG), Authoring Tool Accessibility Guidelines (ATAG) and Accessible Rich Internet Applications (WAI-ARIA);
- The US Section 508 of the Rehabilitation Act.
Apart from the real accessibility needs present in the world, compliance to these two standards is a requirement for many companies and public agencies.
Certification
Resources permitting, we'll be working to certify our accessibility compliance, making the results of our efforts tangible and trustable.
Not a certification tool, but for Section 508, a common communication approach for compliance is the Voluntary Product Accessibility Template (VPAT).
The Real World
Standards are good, at the bureaucratic point of view. But our main purpose is really making our editor effectively usable by people with disabilities. The most important thing is giving our end users a wonderful editing experience, not only satisfying the checklists defined by the standards.
We invite accessibility experts and end users to participate, helping us providing the dreamed accessibility solution for browser based editing.
Features
[TODO: List the features we need to provide for accessibility and standards compliance]