Technology that we develop ourselves may receive higher scrutiny than technology supplied by vendors, since our internal development teams have full control over accessibility outcomes.
Everyone engaged in the development of information technology has a role to play.
Suggestions
- Agile practices. Iterative development and good communication lead to better accessibility outcomes. Checking accessibility of small chunks of a project as they are built is instructive. Checking everything at the end may result in slipped deadlines, little learning.
- Accessible frameworks. If you use a framework that was built with accessibility in mind, you get those included accessibility benefits for free if you use the components built into the framework.
- “Learning” as well as “meeting requirements.” Accessibility will be much more enjoyable if the product team view it as an opportunity to learn something, rather than a checklist of requirements that must be met before a product can be put into production.
Strategies for successful outcomes
These are items that we have found to lead to successful outcomes in the past.
- Review design. Encourage UX folks on project to study our annotating wireframes document (there is also a video) and then annotate the wireframes.
- Choose a front end framework that will help, rather than hinder. See our documentation on front-end frameworks.
- Perform a non-technical review accessibility review of components (reusable and repeated pieces of user interfaces such as menus, forms, etc).
- Incorporate functional accessibility testing into standard QA practices
- Consult the risk assessment documentation to determine risk level and contact the accessibility team for review if the project is high risk.
Before we perform the review there must be evidence of commitment from the team:- Team has reviewed the design and annotated it for accessibility
- Team has performed at least the non-technical accessibility review; optimally they have also carried out a full functional accessibility review.
- If there are inevitable barriers in the product on launch, document them and share with the accessibility team. This will help central support to field inquiries and provide workarounds.
- Think about these suggestions in any revisions to the IT you are creating. All major versions should incorporate a regression accessibility test.