What is accessibility?
Accessibility (also abbreviated as a11y) is making sure that the greatest number of users are able to access and use your product.
Accessibility is inclusion
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.
Accessibility compliance and beyond
All software projects Truss works on need to be ADA compliant in some way. That makes it a legal requirement to ensure all digital products are accessible. Common thresholds for compliance include 508 and WCAG.
You can be compliant and still not make accessible software. True accessibility is about making sure things work for people.
Accessibility is important during the entire project lifecycle
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.
Accessibility is important across practices
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.
Accessibility also applies to the processes used by a team during a project. Many disabilities are invisible and/or undisclosed, so it’s best practice to uphold basic accessibility standards at all times. Some good practices for holding accessible meetings, writing accessible documentation, and using accessible tools include:
- Making sure that documents have content structure e.g. headings so that assistive technology users can effectively navigate the content
- Share meeting materials in advance of scheduled meetings
- Provide captions and transcriptions for meetings
- Using the tool’s built in features e.g. Zoom hand raise
Additional Truss Resources for Accessibility
- Truss accessibility wiki - The wiki covers a range of topics including various form elements, patterns, implementation suggestions with rationale, examples and specific guidance on how to design and build various components
- Drafting an Accessibility Plan - A guide to developing an a11y plan for your project and executing on it
- Sample Github PR template - PR template that teams can use to include accessibility requirements into their pull request process. Includes specific checklists for Q&A.
- Sample breakdown of accessibility testing process (linked in PR template)
- Sample diagram of a cross-practice development acceptance flow
- A11y Quick-Guide for Truss Sales - guidance on how to talk about accessibility from a sales / marketing perspective
- Accessibility Scorecard template - accessibility benchmarks suggested by #g-accessibility