Accessibility Statement

Digita11y Accessible Inc. was engaged to provide accessibility training to co-op students with a software background at Centennial College, and then to lead those students through auditing the content of a number of new courses/resources being developed by the College and their partners. The courses/resources were audited to WCAG 2.0 level AA success criteria.

For this exercise, the “Extending into the Open” Pressbook content  itself was investigated for accessibility issues, rather than the Pressbook  systems used to host the material. This separation of concerns is an accepted approach to dealing with content where the hosting platforms are tested for conformance separately to the content hosted upon them. It does however mean that the course/resource itself cannot receive the form of conformance statement identified in chapter 5 of WCAG 2.0 as section 5.2.2 requires full pages for a conformance statement.

The students were trained:

1. To visually inspect each page (and it was each page of each course/resource, no sampling was undertaken) for layout issues
2. To run automated testing tools and utilize accessibility bookmarklets to inspect the semantic structure of each page
3. To navigate each page with the keyboard, using screen magnification, and using screen-readers to identify navigation issues.
4. To inspect multimedia content for availability of closed caption, and to check that the captions were associated with the content and transcripts (in once case they were not).
5. To inspect PDF documents for accessibility using the PAC 2021 PDF automated testing tool, and to navigate those PDFs with a screen-reader.
6. To specifically inspect alternative text descriptions for images for appropriate content.
7. To inspect content for use of colour and colour contrast issues related to accessibility.
8. To inspect online forms for appropriate error handling when used in conjunction with screen-readers.
9. To inspect each page in both desktop and mobile form, looking for accessibility issues related to responsive design.
10. To utilized a cloud-based web auditing and reporting tool, A11Yn from Digita11y Accessible to record all issues found.

Each course/resource was recoded individually within the A11Yn tool as a separate project. That project had entries for each page of the course/resource with screenshots of the page in desktop and mobile form to provide traceability of the page a time of audit. These screenshots are timestamped.

Each accessibility concern found for a page was entered into the A11Yn tool as a ticket. That ticket was date-stamped, and where appropriate screenshots were uploaded into A11Yn to illustrate the issue a hand. All changes to those tickets were also time-stamped.

For each ticket:

1. A description of the ticket was created
2. Screenshots of the issue were recorded, where possible also showing the source code at issue, and the output of any automated tool used.
3. Steps to reproduce the issue were recorded.
4. The WCAG success criteria associated with the issue were recorded.
5. The issues were assessed for priority (critical, serious, moderate, minor)
6. The complexity of the issue in terms of remediation was identified (within the limits of the student’s software development knowledge).
7. An impact statement was created identifying whom the issue most impacted in terms of accessibility, and how.
8. Recommendations were made to help remediate the issue.
9. The ticket was set into “To Do” state inside the A11Yn tool (A11Yn supports a lifecycle for issue remediation that begins at To Do and end is Closed as remediation is re-tested before close).

At the end of each audit, the students peer-reviewed the tickets raised for correctness, and the tickets were further sampled by Digita11y Accessible.

For each development team involved in the creation of the courses/resources, a presentation was made by students to the developers to highlight and explain the top issues found for the course/resource, and the most common issues found. A Q&A session between developers, student auditors, and a professional auditor from Digita11y Accessible then followed.

All of the raised tickets are visible in A11Yn to the developers to allow for remediation to proceed.

At the time of writing, the development team has remediated all the issues. However, remediation must be re-reviewed by the auditors. The A11Yn tool allows for the development to flag when that remediation is ready for re-review. A messaging system allows for time-stamped traceable discussion threads between developers and auditors over issues as remediation progresses.