Websites

New to using this roadmap? Start on the Digital Accessibility Compliance Roadmap page to understand the structure of the roadmap, how to use it, and how to get help.

Websites and web applications are hosted and built on a variety of platforms at U-M to serve many purposes. In general, websites are static pages that display information to users (e.g., department websites, lab research pages), whereas web applications have dynamic content that changes based on user interactions (e.g., Wolverine Access, MCommunity, web forms). Features that help make web spaces accessible include headings, alternative text, color contrast, hyperlink text, and use of native HTML elements, among many others.

Open book and shining lightbulb icon

Learn

Who is responsible?

  • Anyone who manages or edits web content for their team/department.
  • Instructors that host course content on websites (outside of Canvas).
  • Web designers and developers.

What do you need to know?

Web Content (Non-Technical):

Learn about accessibility in specific web content management systems (CMS): Drupal and WordPress are the most common web CMS tools used at U-M. Others include Adobe Experience Manager (AEM), Google Sites, SharePoint Online, and Wix.

Websites and Web Applications (Technical):

Web Forms & Surveys: 

Document inspected with magnifying glass icon

Review

Who is responsible?

Anyone who designs, develops or maintains websites for university courses, departments, and projects.

Process for review

Use the website inventory spreadsheet (or create your own system) to track which webpages and applications you are responsible for. 

Step 1: Inventory your websites

In your inventory, note page titles, URL locations, and whether they are currently in use/up-to-date. Consider removing or archiving any webpages which are no longer in use. For web pages that are currently in use, note the CMS format (i.e. WordPress, Drupal, etc.), whether the page is static (information-based) or dynamic (interactive, changes based on user input), whether it is public-access or U-M login only, and whether you have edit access to the site (if not, list the contact person that does). This information will guide the approach to remediation.

If you are inventorying websites for an entire unit or department (or maintain a lot of webpages), look into the ITS Accessibility Scanning service.

Step 2: Assess use and risk

  1. Is the webpage still in use? If not, consider archiving it if you are the owner.
  2. Is the webpage either a) located on a main, high-profile public website, b) required to perform well in a course, or c) frequently visited and/or updated? If yes, mark "high priority content."
  3. Does this webpage contain a web form, complex components, custom design elements, or page content that changes based on user interaction (i.e. filtered search displays, "live" changes to content without reloading the page), mark the webpage as “high priority content.” Be aware that many potential accessibility issues with dynamic content will not be caught by a scanning tool.

Step 3: Prioritize web pages for remediation

Webpages that don't require remediation:

  • Pages that are archived (this is NOT the same as pages that "store archival content")
  • Pages that have been reviewed for accessibility within the last 12 months by the ITS Accessibility team or the Disability Equity Office, with no additional changes made to the content, design, or components since then, and no known/reported access barriers.

For all other webpages, prioritization recommendations are below.

High priority: Webpages that are marked "high priority content" in step 2b or 2c, pages with dynamic content, or pages that you have received accessibility complaints about.

Lower priority: Static webpages with no known access barriers reported.

Step 4: Assess accessibility

Run an accessibility scan of the webpage. There are a few different tools to do this. If you are comfortable with HTML, you can use axe DevTools, Accessibility Insights for Web (Google Chrome Extension, Microsoft Edge Extension), Lighthouse or ARC Toolkit. If you have less technical experience or familiarity with HTML, you can use WAVE (Google Chrome Extension, Microsoft Edge Extension). All of these tools provide information on potential access barriers on a singular webpage (not the entire website). If you are seeing issues flagged, the webpage needs to be remediated.

For scanning an entire website, or multiple websites:

Our website accessibility scanning service will soon be launching SiteImprove as its primary tool for scanning websites. More information on utilizing this tool is forthcoming.

If you are interested in exploring other automated options, check out W3C's Web Accessibility Evaluation Tools List.

Disclaimer: Automated accessibility checkers cannot find 100% of issues (usually only 40-80%). They provide a good starting place for identifying access issues across large websites, but always require some level of manual verification. This is especially true with web applications, forms, or dynamic pages with custom design elements or complex components.

Hammer icon

Remediate

Who is responsible?

Units and teams will need to determine who is responsible for remediating websites. Those that maintain web content can be responsible for adding alt text to visuals, descriptive hyperlinks, color contrast, proper use of headings, and text formatting and layout.

Access issues with web components, complex applications or forms, page layout and navigation menus, and other built-in style or design aspects likely need to be addressed by the site developer or designer.

What standards do you need to meet?

Websites and web applications must follow the Web Content Accessibility Guidelines (WCAG) 2.1 AA, as recommended by W3C (World Wide Web Consortium). These guidelines are referenced in U-M's Electronic and Information Technology SPG as well as the ADA Title II federal regulations.

What could a remediation workflow look like?

Start by reviewing best practices for websites (non-technical accessibility quick tips, technical web accessibility checklist), and running an automated scan of the webpage using WAVE, Axe DevTools, or another web accessibility tool.

For web content editors:

  1. In addition to the automated accessibility scan, do a manual test of the page. If you are less familiar/comfortable with HTML, you can follow these steps for quick non-technical accessibility tests. These tests are not comprehensive of all potential access issues on a site, but offer a good "spot check" for the accessibility of the page and can often indicate underlying, more technical issues.
  2. Many access issues can be resolved at the content-level by web content managers or editors. These include using semantic headings, formatting lists and tables correctly, adding alt text and long descriptions to images and complex visuals, providing descriptive hyperlink text, selecting text colors with sufficient contrast and legible fonts, and captioning videos.
  3. If you come across an access issue that you cannot resolve at the content-level (i.e. illegible font size or typeface that is preset with the CMS, color contrast issues built into the design template), contact the web designer or developer(s) responsible for the site.

For website designers or developers:

  1. When conducting a review of a site, start with the Technical Review Template to log issues (or use your own spreadsheet tracking system). If reviewing an entire website (not a single webpage), it is helpful to start with the home page, an index/landing page, a typical subpage, and a more complex subpage, as these can be indicative of repeated issues across the site (or part of the page templates).
  2. Follow the tests laid out in Testing for Web Accessibility. The Global Tests are relevant to almost all websites, and the Specific Tests include test criteria for web forms, font icons, and SVG graphics. These tests not only help identify access issues, but explain expected behavior for web elements to meet WCAG success criteria (i.e. "fixes").

For web applications:

The same principles for accessibility of static websites (listed in the section above) apply to web applications, but with a few additional aspects to be aware of:

  1. Rather than testing by "page type", it is often helpful to test by workflow, or the series of steps that a user will take as they interact with the application. When deciding which test cases to start with, think about which workflows are most critical to the function of the application, as well as which are most frequently utilized. As you step through each page or component the user would interact with, review it for the applicable accessibility tests (Global Tests, Specific Tests).
  2. Due to the complex nature of web applications, automated web scanning tools are less likely to identify potential access barriers, which makes manual testing even more critical in this process. Some specific accessibility resources in this area include web forms (web form controls in HTML, advanced web forms with ARIA, custom controls), carousels, filters (search results, sortable tables), modal dialogs, accordions, drop-down menus, custom components, same page context changes (alerts, pop-ups, content changes), and tooltips. This is by no means an exhaustive list, and we advise reaching out to ITS Accessibility for help with a complex component/accessibility need.

Optional: For more extensive accessibility testing on web applications, it can be useful to run through user workflows with a screen reader. Windows users can test with NVDA or JAWS, and Mac users can test with VoiceOver. Refer to the WebAIM screen reader guides in the tools list below for more help with using screen readers to evaluate web accessibility.

What tools are available?

Automated Tools:

Those comfortable with HTML can use AxeDev Tools or ARC Toolkit for iterative webpage scanning and checking. Those not familiar with HTML can use WAVE for web page scanning.

Instructors can use Panorama for scanning and remediating Canvas Pages on their course sites. The same web accessibility principles apply with Canvas Page content.

Manual Tools/Resources:

IT Technical Review Spreadsheet (Optional U-M Resource, intended for technical developers/designers tracking access issues across websites or applications)

Web Accessibility Testing Guide (U-M Resource, technical)

Using Screen Readers to Evaluate Web Accessibility:

Bar chart icon depicting upward trend

Monitor & Improve

Who is responsible?

  • Web designers and developers are responsible for integrating accessibility practices into their workflows, in both design and functional testing, rather than relying on retroactive testing/remediation.
  • Web content editors and managers are responsible for maintaining the accessibility of websites in the long-term, as even accessible templates can be rendered inaccessible if content is not uploaded and added to the site in an accessible manner.
  • Individuals with ownership over websites with access to data dashboards are responsible for monitoring accessibility scans and reviewing high-level insights to their sites' accessibility and overall progress. 

How to establish a monitoring plan

Your inventory of webpages and applications should be periodically reviewed and updated to determine if remediation work is needed. It is a good idea to routinely review your site for accessibility a few times a year, but at the very least, it should be reviewed each time a change is made to the site, depending on the scope and scale of the change.

For instance, when new page content is added, the content on that page alone should be checked for accessibility. When a new component is introduced, the design and functionality should be thoroughly tested for accessibility, as well as the page template it will be added to. When a site's page hierarchy/navigation structure is altered, the menu components across the entire website should be tested for accessibility.

How to integrate improvements into workflows

Install web accessibility scanning tools as extensions within your preferred browser (this makes it easier to iteratively check on websites as you're viewing them).

As new websites and applications are created, designers and developers can implement accessible design practices from the start, and drastically decrease the need for remediation work later on. Incorporate accessibility testing as part of your development process - there is no need to separate it out from design review or functional testing, or tackle it after everything else is completed. 

If you identify potential access barriers on a site your team/dept is responsible for, contact the site owner, and/or the web designer/developer, to remediate the issue. If you encounter an access barrier on a site, but aren't sure who to contact, you can always report an access barrier to ECRT.

Get Help

For assistance using and adapting the roadmap or navigating compliance concerns, request a Disability Equity Office consultation.

For technical assistance with U-M supported digital accessibility tools or questions about remediating complex formats, contact the ITS Digital Accessibility team.