.png){kind=link}
This is the primary repository of information and resources surrounding accessibility practices at Truss.
Issues and their progress will be captured on the Github project board.
Discussion and support at #g-accessibility
Accessibility (also abbreviated as a11y) is making sure that a greater number of users are able to access and use your product.
Accessibility is not just making sure that a web application is usable by those with physical limitations. While it is very important for those that rely on screen readers and other assistive devices to be able to use the application, other limiting factors can include: type of device, language, content, bandwidth, etc. Ideally we wish to include as many different types of users and situations to be able to access our application as realistically as we can.
All federal web applications have accessibility requirements (typically written into contracts) which may also apply at the state and city level. Common thresholds for compliance include 508 and WCAG 2.1 AA.
While not commonly required, we should also be aware of why accessibility can be important for commercial applications as well. Commercial applications may be subject to legal, legislative, reputation, and/or ethical reasons to follow accessibility guidelines.
Accessibility needs to be incorporated throughout the entire lifecycle of a project, it should not be incorporated as an afterthought or checked only towards the end. It is much easier to address issues during feature conception, development, and story creation phases; as a consequence, it will save time and therefore become more cost effective for the project.
Every role in the project should be aware of the importance of accessibility and have a basic understanding of how they are addressed (even if they only know to look at this guide as a reference first). Accessibility should not be beholden to only one practice to address (e.g. just engineers to fix tags or designers to figure out color and content), but it should be the shared responsibility of everyone on the project. An effective team can work together to make sure that accessibility concerns are met throughout the entire project lifecycle.
For accessibility to be integrated into our agile, iterative practices, teams need to establish agreed-upon processes.
- Accessibility Conformance Report (ACR) for the Trusted Tester Process spreadsheet with automated WCAG 2.0 and disability impact reports
- Truss Accessibility Scorecard
- Drafting an Accessibility Plan
- Sample Github PR template with checklists for accessibility QA
- Sample breakdown of accessibilty testing process (linked in PR template)
- Sample diagram of a cross-practice development acceptance flow
- How to access screen readers through AssistivLabs and JAWS: How to JAWS like a Trussel
.png){kind=link}
You can use the wiki to find tips and recommendations on how to make your website accessible. This covers a range of topics including various form elements, patterns, implementation suggestions with rationale, examples and resources.