Accessibility Improvement Process

Contents

Web Content Accessibility Guidelines (WCAG v2.0)

Websites and web site content must be developed and maintained with attention to accessibility standards and in compliance with Section 504 and 508 of the Rehabilitation Act, the Americans with Disabilities Act, and university non-discrimination policies. All websites to the extent feasible, must be made accessible to people with disabilities. If it is not feasible, alternative methods must be made available to complete the same tasks. Compliance with the WCAG Standard 2.0 Level AA (including Level A) standard is required. Accessibility Efforts and Toolkits has more information about accessibility in general. This article will highlight the process of how to improve accessibility with legacy, open source and vendor applications.

It is suggested that system engineers and developers understand how to use a screenreader (such as ChromeVox) and understand WCAG v2.0 Level AA and Level A guidelines. The ultimate goal should be the ability to successfully use your application with only a keyboard (no mouse) and a screenreader and have no issues with aXe or SiteImprove. If this is not the case, then you should be noting these issues and bringing them up as items to improve upon.

There is training available in Skillsoft and online, links are available in the Accessibility Toolkit.

Discovering and Logging Accessibility Issues

There are various tools to help find accessibility issues within a web page. To get started install a browser plugin/extensions such as aXe or SiteImprove for scanning a web page (more options available above in the Accessibility Efforts and Toolkits). Log the various issues that the tool finds in a spreadsheet.

Examples of what to log

  • Date of Scan
  • Application Name
  • Application Version
  • Page URL
  • Area of Concern
  • Violation (i.e. Elements must have sufficient color contrast)
  • Number of Violations
  • Severity or Impact (i.e. High, Low)
  • Tool Used for Scanning (i.e. aXe, manually, WAVE)

Logging should be done for every page in the application. Once these items are logged it would be good to create a Footprints ticket with the priority of "Compliance".

After this you have to determine how will these items be addressed and repaired. Some items might be able to be patched through configuration, theming, or code manipulation.

A scan of software should be done whenever a change or upgrade occurs to see if the product still is compliant. Additionally standards change over time for instance WCAG v2.1 should be released in 2018 and we might need to scan again once the University changes their base standard.

Continuing the Process for Vendor Applications

There are accessibility issues identified. The next step is to review the items in question. Typically issues in a vendor application under our control are in the theme, configurations or helper text. Examples of how we've made changes for compliance: Background colors of banners should typically be set to: brown #877148 with white #FFFFFF text on top (similar to the KB template).

Once you fix all the items you can, submit the remainder of accessibility changes to the vendor to review and to patch.

Once a patch is issued, test the changes against your spreadsheet of issues to verify the items were patched, you'll have to also document any new issues if any occur.

Continuing the Process for Legacy Applications (Created by Oakland University Developers)

Legacy applications mean the responsibility of coding the solution is on our staff and there is no third party to collaborate. All items must be patched to meet WCAG v2 Level AA and A guidelines. aXe and other automated scanners can say your site is compliant, although not user-friendly to someone with disabilities. We strive to be both compliant and have usable applications.

Once a patch is issued, test the changes against your spreadsheet of issues to verify the items were patched, you'll have to also document any new issues if any occur.

Continuing the Process for Open Source

Open source is similar to legacy, you have to be the main driver of getting the change into the product. Some communities are not open to anyone changing their code, so raising the issue on mailing lists or adding an issue to their repositories might be a start. For other communities such as Apereo, pull requests from OU developers can be made, although it can be hard get your changes accepted in some cases. You have to be an advocate for the change and help prove the change is needed.

In some cases, such as with products as MoinMoin, Shibboleth or uPortal we've created a code repository in code.oakland.edu with the changes we've made to make the product more compliant and need to add these modifications with each upgrade.

Once a patch is issued from the open source community or a delta is created by OU developers, test the changes against your spreadsheet of issues to verify the items were patched, you'll have to also document any new issues if any occur.

Documenting Improvements

Once an item has been patched, please document this effort so we can add this to our documentation for the Office of Civil Rights.

Issues Becoming Compliant

If you are having issues with a third party or you can't make the code compliant to standards have a discussion with your supervisor and colleagues about the matter. There are often solutions to be had that are not straight forward. In some cases you may need to escalate this to someone to challenge the contract. All vendor purchased products must answer questions on accessibility (VPATs).

March 2018

  • DBHowTo