As a part of our pre-sprint planning, Greg Clapp provided an in-depth study of accessibility best practices and recommendations for our approach. The draft is included below and will influence our approach.

Objective

Ensure the new portlandoregon.gov website provides equal access to all visitors regardless of visual, mobility, auditory, and cognitive abilities, by establishing a set of standards, tools and processes to help developers correctly plan, design, and develop the project; and by discussing tools and methods to support content editors in providing accessible content.

Open Questions

• Will we be establishing a target comprehension level for site content? If so, what is the target?

Purpose of this document

• Evaluate and compare accessibility testing tools

• Discuss areas where automated testing is not sufficient to meet accessibility goals

• Make recommendations for integrating accessibility testing into the development process, and for ongoing testing pages and content as it is entered by site editors

Challenges

• Developers will need to adopt accessibility as a mindset, and integrate best practices throughout the planning, development and acceptance phases, not just as a final test;

• Accessibility best practices will need to be integrated into content editor training; features and processes will need to be developed to re-enforce these practices

• The legacy site contains numerous electronic documents and time-based media that must be individually addressed [How many? What is the impact?]

References

1. WCAG 2.0 Checklist - https://webaim.org/standards/wcag/checklist
   This checklist cannot be used to verify conformance with WCAG 2.0, and should not be referenced in policies or policy adoption. It is intended to be a helpful, informational resource for technical implementation, recommended techniques, and success criteria. It is WebAIM’s interpretation of the guidelines and success criteria.

2. Web Content Accessibility Guidelines 2.0 - http://romeo.elsevier.com/accessibility_checklist/
   Very clear, easy to understand checklist that includes WCAG 2.0 and Section 508 guidelines.

3. Web Content Accessibility Guidelines (WCAG) 2.0 - https://www.w3.org/TR/WCAG20/
   This is the official specification that should be referenced when determining policy and success criteria.

4. W3C WAI Evaluation Tools List - https://www.w3.org/WAI/ER/tools/
   A comprehensive list of accessibility evaluation tools

5. Accessible SVGs - https://css-tricks.com/accessible-svgs/
   Useful reference of accessibility best practices for SVG images. 

Standards

The POWR project will adopt the A and AA levels of conformance as described by the WCAG 2.0 guidelines. Where feasible based on timeline and budget, the project will attempt to meet the AAA level. 

The official W3C guidelines outline the following four principles of accessibility and associated guidelines:

1. Perceivable

   1. Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

   2. Provide alternatives for time-based media.

   3. Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

   4. Make it easier for users to see and hear content including separating foreground from background.

2. Operable

   1. Make all functionality available from a keyboard.

   2. Provide users enough time to read and use content.

   3. Do not design content in a way that is known to cause seizures.

   4. Provide ways to help users navigate, find content, and determine where they are.

3. Understandable

   1. Make text content readable and understandable.

   2. Make Web pages appear and operate in predictable ways.

   3. Help users avoid and correct mistakes.

4. Robust

   1. Maximize compatibility with current and future user agents, including assistive technologies.

Not all of these guidelines can be thoroughly tested using automated tools. The tools can identify when page headings are out of hierarchical order, whether landmarks and ARIA enhancements are used, or whether alternative text is missing from images, for example, but it cannot determine whether the headings or alt text convey appropriate meaning, or whether the “pages appear and operate in predictable ways.” Human evaluation will always be needed to ensure the project conforms to the more subjective guidelines.

The base CMS for the POWR project, Drupal 8, includes numerous features to support accessibility and the WCAG 2.0 standard, both for developers and content editors, which are not described in this document. However, testing processes should be established to set a baseline of compliance and ensure the accessibility goals are being met.

Testing Tools

Several classes of accessibility testing tools are described here, for testing web pages, electronic documents, and content. The tools are further identified by type:

• Browser extensions (“Ext”)

• Desktop applications (“Desktop”)

• Command line interface applications (“CLI”)

• Web-based applications (“Web”)

• Applications that have an API that can be integrated into other tools (“API”)

Web Page Testing Tools

Electronic Document Testing Tools

Electronic documents must also be tested for accessibility, though there are scant free or low cost tools available for automated testing, and none were found that can scan files while crawling a site. Manual document testing and manual updates will be required.

Additional References

Create Accessible Electronic Documents (Section 508) - https://www.section508.gov/content/build/create-accessible-documents

PDF Testing Tools

Office Document Testing Tools

Additional References

[WebAIM] Microsoft Word - Creating Accessible Documents - https://webaim.org/techniques/word/

Content Testing

Determining whether text content is readable and understandable is particularly challenging. Tools exist that can roughly determine the reading level of text content, but overall, content must be manually reviewed by humans. This requires thoughtful evaluation and use of checklists to determine adherence to the WCAG principles.

Microsoft Word and Outlook have a built-in tool to estimate the Flesch-Kincaid readability level of documents. There are also numerous online testers available for analysis of individual web pages or text snippets, and there may exist tools that can crawl entire websites, if that level of content testing is desired.

It would be handy to utilize a built-in readability checker in the new CMS, but no Drupal 8 modules currently exist for this. There are some modules for Drupal 7 that we might consider porting to 8 if this is a desirable feature.

Additional References

Legibility, Readability, and Comprehension: Making Users Read Your Words - https://www.nngroup.com/articles/legibility-readability-comprehension/

Recommendations

• Developers utilize built-in Drupal 8 accessibility features as much as possible.

• Developers use one of the browser extensions or bookmarklets to periodically test files/templates/pages during development and unit testing. Every template, widget, page, etc., should be checked before acceptance and promotion. The WAVE Evaluation Tool, or similar browser extension, is recommended.

• The full site is fully tested at the end of each sprint using a crawler tool, as part of acceptance. In-depth evaluation of the crawler tools is needed before a specific recommendation can be made.

• After/during content migration, all electronic documents (PDF, DOC, PPT, etc.) to be retained are scanned for accessibility compliance and updated accordingly, or alternate content is created.

• After/during content migration, site is scanned using a crawler tool to identify any issues in both legacy and newly created content.

• After launch, the site is scanned on a regular basis using a crawler tool to verify accessibility standards are being followed by editors and allow issues to be resolved. This includes scanning of electronic documents, if feasible.

• Use of Continuous Integration tools for accessibility testing is not recommended, since CI testing is only as useful as accessibility can be verified in Drupal code files or in the content that exists in the integration environment. This seems like it would be more trouble than it’s worth.

• Accessibility issues are considered bugs, given the same gravity as other code defects, and logged and processed as such. The severity of the defect is somewhat related to the WCAG criteria level (A, AA, AAA).

• Tools, messaging and documentation are integrated into the new CMS to help content editors create accessible content and documents.

• If there are comprehension and reading level requirements, additional study will need to be made of testing tools and techniques, as well as tools for assisting content editors.