Testing for Accessibility
Testing for Accessibility
Not all content editors need to be familiar with (and checking) SiteImprove at regular intervals (at least once a semester). However, there needs to at least be one “super user” for each area or template that can keep an eye on the SiteImprove reports and work with staff who publish content that isn’t accessible.
If you will be the person in your unit who checks SiteImprove periodically to ensure your content remains compliant over time and you're not signed up yet, go to CIT's SiteImprove page to set up your Siteimprove account to have your entire site scanned. Once you're set up, read this article on How To Use Siteimprove.
Developers, Designers and Project Managers
We recommend that developers, designers and project managers who are new to web accessiblity review the Testing for Compliance: Where to Begin? presentation done by CIT at 2018 Web Accessibility Camp. Below is a summary from that presentation.
- Accessibility testing plays a key part throughout the entire development life cycle:
- Tests should be written during the planning phase based on accessibility requirements.
- Developers should conduct automated tests, keyboard accessibility tests, and screen reader testing of custom widgets during the build/creation phase.
- Comprehensive manual testing and QA should be performed to identify accessibility issues missed during the previous phases of development.
- Everyone has a role in creating accessible web content.
- A methodology should be established in order for the testing process to be effective, such as:
- Define the scope of the evaluation
- Conduct automated tests and manual tests
- Document all findings in a detailed report
- Plan for remediation based on findings from tests
- Conduct regression testing to evaluate fixes
- Automated testing can be used to quickly identify issues (i.e., SiteImprove, Wave, Color Contrast Checker)
- Manual testing needs to be conducted to validate automated tests and to discover issues that automated tests cannot identify (see details below)
- Bug Reports for accessibility issues need to be composed in a format that allows designers, developers, and other stakeholders to successfully address accessibility issues.
- Issues should be prioritized based on factors like business value, risk, visibility of issues, and severity of issues.
- Regression testing and monitoring should be conducted to identify issues that may emerge from previous remediation efforts.
- Tab Focus ability and order
- Keyboard Functionality (with and without screen reader)
- Visual Focus indicator
- Effective focus managements (forms, dialogs, dynamic content)
- Keyboard Traps
- Test for meaning conveyed with color
- Test alt text quality
- Test video/audio accessibility
- Test for landmarks
- Test link text quality
- Test form labels and instructions
- Test form validation
- Test custom widgets
Testing Resources for...
- Keyboard Testing
- Testing with Screen Readers
- Testing with NVDA
- Testing with Voice Over
- Testing Color Contrast — You can test color contrast with the tools like Siteimprove, WAVE and the WCAG Color Analyzer. For a more accurate test, use WCAG Color Contrast Analyzer. You will be able to use it with PDFs and images as well as HTML pages. NOTE: Most tools use website CSS to compare foreground & background. This means if there is a background image, gradient, or complex CSS positioning, it will not be measured correctly.