Accessibility Reviews
Web Accessibility Testing Best Practices for Developers and Designers
Introduction
The University of Maryland is committed to making all of our websites and digital properties accessible to all users, including our community with disabilities. Developers and designers need to check all websites and digital properties for accessibility through both automated and manual testing in order to meet with the University of Maryland web accessibility policy, improve search engine optimization (SEO), and continuously work towards providing an inclusive and equitable experience for all.
This document gives a high-level overview and best practices of what to check for on your website manually and with automated tools prior to a launch. These best practices should also be incorporated during the post-launch and maintenance phases of a website and can serve as a reference for third-party vendors. All new components and elements added to a website should be continuously created and evaluated with accessibility in mind and following WCAG 2 Guidelines, content creators and those seeking general web accessibility evaluation guidance may also refer to the UMD Web Accessibility Evaluation Guidelines.
Accessibility is the responsibility of everyone and is something that should be continuously integrated into every phase of the website and digital content development process.
Automated Checks
Automated checks are performed using testing tools to scan a website’s code and find potential common accessibility barriers such as heading structures, alternative text, meaningful link text, contrast errors, and form field labels. These scans give an overview of how the website adheres to web accessibility standards and highlights potential areas for improvement. Automated scans are not an absolute indicator of the state of the website’s accessibility, but they are good starting points. All automated checks should always be followed with a thorough manual review of the website.
SiteImprove
SiteImprove is a third-party web-governance software solution that can be used to perform quality checks on your website. With SiteImprove, you can set a target score that matches WCAG 2.0 AA (the current standard for University of Maryland web properties). The university’s target SiteImprove score for all websites is 751. All University of Maryland campus partners have access to SiteImprove. It is required that all university websites be added to the SiteImprove platform so that they can go through an automated scan. Contact UMD DIT Accessibility team to request your site to be added to Siteimprove.
WAVE
All website homepages should be checked with the WAVE browser extension, available for both Chrome and Firefox browsers, that is provided by WebAIM. WAVE can give a quick indication of any accessibility barriers (such as color and contrast, form labels, heading structure, alternative text, and meaningful link text) on your website. It is to be noted that WAVE scans the current page and not the entire website.
Lighthouse
Additionally, developers may also use in-browser tools, such as Lighthouse within Chrome DevTools to identify any potential accessibility barriers.
1 SiteImprove has a new NextGen Accessibility module, based on the WCAG 2.1 and ACT Rules Format 1.0 , therefore current metrics are subject to change.
Manual Checks
Automated tests can only detect up to 30 percent of issues on websites that cause accessibility barriers. It is important to manually review all components of a website in different ways to ensure that information is being conveyed accurately and appropriately. A website must undergo a manual evaluation with consideration to the listed components prior to a launch. Manual checks should be conducted iteratively during the post-launch and maintenance phases.
- Keyboard Navigation: Is the website operable with keyboard only? (no mouse)
- Tab navigation (Can you tab to all interactive elements on the website in a logical order?)
- Are there focus indicator borders around all interactive elements (links, buttons, menu items, form fields)?
- Can you use the up and down arrow keys to navigate within a dropdown? (including drop down menu navigation)
- Can you navigate to submenu items within a menu?
- Enter/Return keys for submission and selection
- Can you use the ESC key to leave an opened element? (i.e. pop up window, open menu, etc.)
- Can you select radio buttons and checkboxes with the space bar (enter/return keys also)?
- Is the focus order logical?
- Tab navigation (Can you tab to all interactive elements on the website in a logical order?)
- Semantic HTML: Ensure that HTML is semantically structured.
- Are proper tags being used?
- For form fields, are there appropriate input types?
- Not every field should be a text field.
- Can something within a divbe replaced with a more appropriate element? (instead of div Play Video use button Play Video)
- Are the correct input types being used? (i.e. “submit” for submit buttons)
- Do all pages have a title? (Do they use the title tag?)
- Are there heading levels that are being skipped? (i.e. jumping from h1 to h3)
- Are subheadings nested properly under one another? (i.e. if you have “News Articles” as an h2, are the article titles h3?
- Are there empty headings? (remove or add the necessary content if this is the case)
- Developers should continuously use WAVE and inspect code using Chrome DevTools.
- Responsive: Ensure that the website is responsive and can operate on multiple displays of varying sizes (i.e. mobile, tablet, laptop, monitor).
- Browser Compatibility: Ensure that the website is compatible and can degrade gracefully without limiting access to content within common browsers such as Chrome, Firefox, Safari, and Microsoft Edge.
- Page Language: Ensure that the language of the page has been established in the html tag. WAVE, SiteImprove and most automated scanners can detect this (Note: University of Maryland campus partners have access to SiteImprove).
- Flashing Content: Flashing or flickering content on a page should not flash longer than three times per second (ideally flashing content should not be present on the website at all).
- Color and Contrast: All text and backgrounds should have a color contrast ratio of 4.5:1 (for regular sized text) or 3:1 (for larger sized text).
- Error messages should have proper color/contrast.
- Check link button background and foreground color to ensure it complies with contrast ratios.
- Ensure that hover and focus states on links and buttons do not affect the contrast ratios.
- Evaluate the contrast of images and graphics using the Color Contrast Analyzer tool to make sure that they comply with the minimum requirements.
- Color should not be the only way to convey important information (example: red equals danger/error and green equals good/passing).
- Carousels and Video Players: Ensure that carousels and video players do not play on their own (Note: carousels are not recommended for presenting important content, however if one must be used, then please check Deque University’s example of an accessible carousel.).
- Is there a play/pause button present on the video player or carousel?
- Does the carousel or video autoplay?
- Is the carousel or video player navigable with a keyboard?
- Labels and Inputs: Ensure that proper labels and input types are being used.
- Are labels being used accordingly? (i.e. are checkboxes identified as checkboxes and not as buttons?)
- Are there form labels associated with input fields?
- Are there empty labels or buttons? (remove or add the necessary content if this is the case)
- Skip to Main Content Links: All websites should have a “Skip to main content” link that should be one of the first items on a page.
- When embedding social media feeds, ensure that there is a “Skip social media feed” link (Note: it is not recommended to add social media embeds on the site due to tedious keyboard and screen reader navigation)
- Refer to WebAIM’s examples of accessible Skip Navigation Links.
- Hoverable Links: Ensure that links have a hover effect on mouseover (i.e. changing color, underlining).
- Tables: Ensure that all tables have the appropriate table headers and table summaries.
- Is the markup appropriate for the table? (proper usage of th, td, col, row)
- Do tables with multiple header cells have ids associated with them?
- Zoom Magnification: Ensure that content on the website does not get distorted from a zoom magnification of 200 - 400 percent. This is a large indicator of what the website will look like on mobile devices.
- Usage of ARIA: Ensure that Accessible Rich Internet Applications (ARIA) is only being used when appropriate.
- ARIA is beneficial for dynamic screen reader notifications such as: displaying search results, notification of form field errors, announcing alerts, page loading notifications, etc. Please see W3C’s recommendations on when ARIA is appropriate to use.
- Ensure that proper roles are set accordingly.
- Do not use ARIA for anything that can be resolved by using a proper input, label, heading, etc. (first rule of ARIA - is to not use it; ARIA should not be resolving unsemantic HTML).
Content
- Per the University of Maryland Web Accessibility Policy, all University of Maryland properties need to have the university’s Web Accessibility statement link in the footer.
- Images and Alternative Text: Ensure all images and graphics of importance have meaningful alternative text.
- Does the alternative text on an image convey the information needed to a non-sighted user?
- Do images have alternative text that start with “image of”, “photo of”, or “graphic of”? (this is not a recommended practice, and is redundant and confusing to screen reader users)
- In this example, the alternative text for the image being described is “President Darryll J. Pines at the Investiture Ceremony on April 22, 2021.” This alternative text conveys enough information about the context of the image without going into excessive detail.
- Are there images that do not need alternative text and can be marked decorative? Please check W3’s alt decision tree to determine whether an image needs alternative text.
- Images do not convey any context (i.e. decorative borders), do not need alternative text and can be marked as decorative.
- alt = “” is used to mark any image that is decorative.
- Are there captions present on relevant images and figures?
- For images of text, are all of the text on the images being put into the alternative text and summarizing the image properly?
- Does the alternative text on an image convey the information needed to a non-sighted user?
- Links and Link Text: Ensure that all links are within context.
- Keep URL structures simple and readable.
- Use hyphens instead of underscores (such as example.com/news-articles instead of example.com/news_articles).
- Are long URLs being used in a sentence instead of contextual anchor text?
- Are link texts conveying enough information to a screen reader user who is not sighted?
- Avoid phrasing links in ways such as: “Click here”, “this”, “read more."
- Reword link phrases to have specific locations, for example: Go to the Office of the President’s website to find more information on the inauguration.
- Are all URLs valid? (check for any 404 errors)
- Are all emails displayed as links using the “mailto:” attribute?
- Keep URL structures simple and readable.
- Abbreviations and Misspellings: Ensure that uncommon abbreviations are written out and check for any misspelled words.
- Are there abbreviations that can be written out?
- Are there uncommon abbreviations present (i.e. “Pos.”, “Ht.”, “Wt.”)? (these should be written out).
- Are there abbreviations that are common with other abbreviations and words? (i.e. APR, Dr., IT, etc.).
- Video and Audio: Ensure that video and audio content of relevance is presented in an accessible format.
- Do all videos with dialogue and sound have closed captioning?
- For video players that do not have a customizable closed captioning option, open captions should be embedded within the video.
- Do captions have a proper and visible foreground and background?
- Are the captions too long? (check to make sure captions do not take up a significant portion of the screen and are broken up adequately)
- Do all videos and audio (i.e. podcast episodes) have transcripts?
- Do videos have audio descriptions? (dependent on context; please check W3’s checklist on when videos need audio descriptions)
- If videos simply have a person speaking and giving information, audio descriptions are likely not needed (i.e. a commencement speech).
- Videos that describe something in particular would benefit from audio descriptions (i.e. describing an island on a virtual tour).
- Do videos have American Sign Language (ASL) interpretation? (dependent on context)
- Do all podcast episodes have transcripts associated with them?
- Do all videos with dialogue and sound have closed captioning?
Tools and Resources
Screen Readers
- JAWS (Windows only, will need a license)
- NVDA (Windows only, free)
- VoiceOver (MacOS only, embedded within system)
- ChromeVox (in-browser screen-reader, free)
- Windows Narrator (Windows only, embedded within system)