Last active
December 24, 2015 14:49
-
-
Save colinbdclark/6815237 to your computer and use it in GitHub Desktop.
Requirements for Accessible Development and Integration
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1. Maintain a clear separation between the content and presentation layers of an application | |
a. CSS must be separate from HTML markup | |
b. CSS and HTML should be independent of the application's server-side and client-side code | |
2. Technical practices | |
a. Comprehensive support for ARIA in all JavaScript-enabled user interfaces | |
b. Validation of CSS, HTML, and code using appropriate W3C or third-party validators | |
c. Comprehensive support for WCAG 2.0 AA or higher through all user interfaces | |
d. All strings must be parameterized as properties files, JSON, or other parseable format for localization | |
3. Responsive and Responsible Design | |
a. Must support and test across multiple form factors, screen resolutions, and browsers | |
b. Must use relative sizing rather than absolute units to ensure cross-device scalability | |
4. Testing | |
a. Comprehensive test plans for cross platform, cross browser, cross device testing | |
b. Regular and frequent testing with assistive technology by both developers and by end-users of these ATs | |
b. unit tests to ensure the longevity of the integration and the modularity of the system | |
5. Continuous integration | |
a. Features should be developed in individual, fine-grained development branches in order to ensure that features can be merged in or backed out as needed | |
b. Always-working builds; broken builds reduce the ability to test for accessibility and to accept contributions from the community | |
6. Modular code design | |
a. No hardcoding of presentation or delivery format: application logic and content delivery mechanisms must be alterable and configuration without modifying substantial code, in order to enable personalization | |
7. Open and auditable | |
a. Community and accessibility experts should be able to audit the underlying code for potential problems or errors | |
b. Ensures contributions from and longevity of community |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment