Bugzilla – Full Text Bug Listing
| Summary: | [Accessibility] should test for accessibility compliance | ||
|---|---|---|---|
| Product: | [Modeling] EEF | Reporter: | Bouchet Stéphane <sbouchet> |
| Component: | General | Assignee: | EEF Inbox <emft.eef-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | stephane.begaudeau |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
The Eclipse EEF team has worked over the past few months on a brand new runtime using a reflective approach which can be used more easily with Eclipse Sirius. Since we do not plan to continue to work on the old runtime and its code generation approach, I will close this issue for now. If you want to contribute, you can reopen this issue and submit a contribution to the project thanks to our Gerrit: https://git.eclipse.org/r/#/admin/projects/eef/org.eclipse.eef |
Projects should design and test for accessibility compliance, following established guidelines and Eclipse fundamental techniques to achieve accessibility. Projects must document their accessibility work and compliance. Ideally this would be by using a publicly available checklists, such as * http://www.itic.org/resources/voluntary-product-accessibility-template-vpat/ * http://www.section508.gov/ * http://www.w3.org/TR/WCAG/ but, given the advice of the Accessibility Cross Project Team, for this year's Helios Simultaneous Release, projects can document their work or compliance as a negative, such as "we did not do any accessibility work or testing and do not know the degree of our compliance". But its important to document, so adopters know. If possible, and appropriate, accessibility testing tools can be leveraged such as NVDA. The main accessibility article at Eclipse Corner has been made current (thanks goes to Todd Creasey).