Skip to main content

Custom Reports

There are several custom reports available in DubBot to help you quickly review and manage the accessibility of the sites you monitor.

Reports for WordPress Admins

If you manage a site on the boisestate.edu WordPress platform, the following reports are customized for you:

  1. Accessibility Quick Wins – Fix Today: this report contains a list of quick wins. These are content related issues that can often be fixed in a minute or less.
  2. Accessibility Cleanup – Review these weekly: this report lists issues that may take a little more time to review and fix.
  3. Accessibility Best Practices: These best practices can improve the overall accessibility and user experience of your content. Review after addressing the quick wins and cleanup items.
  4. Serious Issues: These serious issues are actively monitored by the Web Accessibility team.
  5. Critical Issues: These critical issues are actively monitored by the Web Accessibility team.

Reports for Affiliated Site Admins

If you manage an affiliated university website that is not hosted on the boisestate.edu WordPress platform, we have created several custom reports to help you prioritize the work needed to be completed by the April 2027 ADA Title II Accessibility Compliance deadline:

1. Critical Issues (Resolve by October 2026)

Critical Issues (Resolve by October 2026)

These critical issues must be addressed first, as they represent major barriers that can completely prevent users with disabilities from accessing your site. To stay on track to meet the April 2027 compliance deadline, we strongly recommend resolving these critical issues by October 2026.

Resolving these may require adjusting your existing platform or CMS settings. If a setting isn’t available, you will need to contact your platform developers or technical team immediately to request a code update to meet the October 2026 deadline.

1. Missing Content & Basic Page Structure

These automated checks ensure that screen readers can accurately announce what the page is and what language it is reading.

  • <html> element must have a lang attribute: The code must specify the language of the page (e.g., <html lang=”en”>). Without this, screen readers might use the wrong accent or pronunciation rules.
  • Documents must have <title> element to aid in navigation: Every page needs a unique, descriptive browser title. This is the first thing a screen reader announces and helps users track which tab they have open.

2. Forms & Interactive Elements (Missing Labels)

When elements lack accessible names, screen readers simply announce “button” or “input field” without telling the user what it actually does.

  • Buttons must have discernible text: Icon-only buttons (like a magnifying glass for search or an “X” to close a popup) must have hidden text or an aria-label so screen readers can announce their purpose.
  • Form elements & Select elements must have labels: Every text input, checkbox, and dropdown menu must be programmatically linked to a visible text label so a user knows what information is required.
  • ARIA inputs / commands must have an accessible name: If custom interactive components (like a custom-built dropdown or search bar) are built using ARIA roles, they must include text labels or descriptions (aria-label or aria-labelledby) to bridge the gap between the code and assistive software.
  • Required ARIA attributes must be provided: Certain custom elements require specific helper attributes to function correctly for screen readers (for example, a role=”checkbox” must also have an aria-checked state).

3. Keyboard Navigation & Focus Control

Many users rely entirely on a keyboard (using the Tab key) rather than a mouse. These manual and automated issues ensure they do not get stuck.

  • Manual review – Visual focus indicator: As a user tabs through the site, a visible outline (focus ring) must appear around the active element so they know exactly where they are on the page.
  • Manual review – No keyboard traps: Users must be able to navigate into and out of every element using only a keyboard. A trap happens when a user tabs into a modal popup or calendar picker and cannot close it or escape without a mouse.
  • Scrollable region must have keyboard access: If a specific box or container on the page has its own scrollbars, keyboard-only users must be able to focus on it and use the arrow keys to scroll through the hidden text.

4. Layout, Zoom & Visual Functionality

These issues impact users with low vision, cognitive disabilities, or mobile users who need to alter the page layout to read comfortable.

  • Zooming and scaling must not be disabled: The site configuration must not block users from pinching-to-zoom on mobile devices or using browser zoom settings.
  • Manual review – Form display at zoom to 200%: When the page is zoomed in to 200%, text must not overlap, form fields must not break, and content should not be cut off.
  • Manual review – Expandable content functionality: Components like accordions, “Read More” links, or mobile hamburger menus must cleanly expand, contract, and dynamically announce their open/closed state to assistive technology.

5. Security & Authentication

Manual review – Accessible Authentication (Minimum): The login process must not rely on cognitive hurdles that cause undue strain. For example, if your login requires solving complex puzzles, memorization, or completely blocks users from using password managers/copy-pasting their passwords, an alternative accessible method must be provided.

2. Serious Issues (Resolve by January 2027)

Serious Issues (Resolve by January 2027)

While ‘Critical’ issues often make a site completely unusable for assistive technology, ‘Serious’ issues typically create major friction, confusion, or visual barriers for users with low vision, color blindness, or screen readers.

To stay on track to meet the April 2027 compliance deadline, we strongly recommend resolving these serious issues by January 2027.

Most of these issues can be resolved directly within your site’s content editor (such as updating text contrast or adding alt text to images). However, if you are unable to fix a specific item yourself, you may need to reach out to your platform’s developer to adjust the underlying template or design settings.

1. Visual & Color Contrast Barriers

These issues make text difficult or impossible to read for users with low vision or color blindness.

  • Elements must meet minimum color contrast ratio thresholds: Text color doesn’t contrast enough against its background color (e.g., light gray text on a white background).
  • Links must be distinguishable without relying on color: If a link inside a body paragraph is only identified by color (and not underlined), colorblind users won’t know it’s clickable.

These issues prevent users relying on screen readers from understanding graphics and web links.

  • Images must have alternate text: Decorative or informational images are missing alt tags, so screen readers can’t describe what the picture is showing.
  • [role=”img”] elements must have an alternative text: Custom graphics or icons built with CSS/SVG using the role=”img” tag are missing labels.
  • Link does not have readable (discernible) link text: Links like “Click Here,” “Read More,” or icon-only social links don’t explain where they take the user when read out of context.
  • Frames must have an accessible name: Embedded content (like YouTube videos or Google Maps inside an <iframe>) needs a title attribute (e.g., title=”Store Location Map”).

3. Invalid or Misused ARIA Attributes

ARIA is code used to explain custom widgets to screen readers. If syntax or values are wrong, assistive tech gets confused.

  • ARIA attributes must conform to valid names / values: Attributes have typos or invalid settings (e.g., writing aria-labeldby instead of aria-labelledby, or setting a true/false value to something invalid).
  • Elements must only use permitted / supported ARIA attributes: Using an ARIA attribute on an HTML element that doesn’t support it (e.g., placing table-specific ARIA attributes on a button).
  • Certain ARIA roles must be contained by particular parents / contain particular children: ARIA parent/child pairs are broken. For example, an aria-role=”list” must directly contain aria-role=”listitem”.
  • ARIA progressbar nodes must have an accessible name: Loading bars or step indicators using role=”progressbar” must have a label telling users what is loading.

4. Screen Reader Focus & Hidden Code

These errors cause screen readers to announce things that aren’t actually on the screen or read out bad document structures.

  • ARIA hidden element must not be focusable or contain focusable elements: Code that is hidden visually with aria-hidden=”true” still contains a link or button that users can tab into. This causes the screen reader to focus on “invisible” screen elements.
  • <li> elements must be contained in a <ul> or <ol>: List items exist on their own without a parent bulleted or numbered list tag, which breaks screen reader navigation shortcuts.
  • Interactive controls must not be nested: A clickable element is placed inside another clickable element (e.g., a button inside a link, or a checkbox inside a button).

5. Media & Layout Structure

Media & Tables – Layout Tables: HTML tables were used to build visual page layouts rather than present tabular data. Screen readers try to read these like spreadsheets, making the content confusing.

3. Moderate Issues (Resolve by April 2027)

Moderate Issues (Resolve by April 2027)

While “Critical” and “Serious” issues deal with broken functionality and major visual blockers, “Moderate” issues typically focus on content quality, SEO health, heading structure, and clean coding practices. Fixing these makes the site significantly easier to read, navigate, and maintain.

1. Weak Link Text & URL Issues

Screen reader users often generate a list of all links on a page to scan it quickly. Generic link names tell them nothing about where the link leads.

  • “Click Here”, “Here”, “Learn More”, “Read More” used as link text: Generic phrases force users to read all the surrounding text just to understand what a link does.
  • Full URL address is linked instead of text: Linking a raw URL (like [https://www.example.com/sub/dir/page-id-9283](https://www.example.com/sub/dir/page-id-9283)) forces screen readers to read out every single character and slash, which is tedious for the user.

2. Heading Structure & Typography Problems

Headings act as an outline for the page. Breaking the outline structure makes it hard for low-vision users to grasp the page layout.

  • Content & Navigation – Missing H1: The page completely lacks a primary Level 1 Heading (<h1\>), which functions as the page’s main title.
  • Content & Navigation – Multiple heading 1 (H1) on page: Using more than one H1 per page confuses the hierarchy. A page should ideally have exactly one H1, followed by H2s and H3s for sub-sections.
  • Content & Navigation – Empty Heading: The code contains an empty heading tag (e.g., <h2></h2>). Screen readers announce a heading but read nothing, confusing the user.
  • Content & Navigation – Inaccessible Typography: The site is using fonts that are too thin, compressed, or stylized to be read easily, or text spacing that doesn’t scale cleanly.

3. Poor Alt Text Practices

These are images that technically have alt text, but the quality of the description is useless or repetitive.

  • Alt text is the same as the file name: Screen readers end up reading out alt=”IMG_4829a.jpg”, which provides no helpful context.
  • Image alt text is less than 12 characters: The description is too short to be meaningful (e.g., alt=”logo” or alt=”car”).
  • Media & Tables – Long Alt Text Description: The alt text is overly conversational or longer than 150 characters. Detailed descriptions belong in the body text, not the alt attribute.
  • Media & Tables – Decorative Image Description: Images that are purely decorative (like design flourishes or background shapes) should have empty alt text (alt=””) so screen readers skip them. Giving them descriptions clutters the experience.
  • Media & Tables – Image element contains a title attribute: Hover tooltips (title=”…”) on images often duplicate or conflict with alt text, leading screen readers to read the same description twice.

4. Code Cleanliness & Structural HTML Rules

These code syntax issues can cause pages to render unpredictable layouts or confuse browser styling.

  • <ul> and <ol> must only directly contain <li>, <script> or <template> elements: A list container cannot contain raw text or generic <div> tags directly—only list items (<li>) are permitted as direct children.
  • <svg> elements with an img role must have an alternative text: Scalable vector icons acting as illustrations must include an aria-label or <title> tag.
  • Content & Navigation – Remove B tags: The bold tag (<b>) is outdated. Teams should use the semantic strong tag (<strong>) to indicate emphasis.
  • Content & Navigation – Underlined text: Text that is not a link should never be underlined, as users naturally expect underlined text to be clickable.
  • Content & Navigation – Blockquotes missing cite attribute: Quotation blocks should ideally link to their source using a cite=”…” URL attribute.
  • Content & Navigation – Directional Terms: The text uses visual instructions like “Click the button on the right” or “See the graphic below.” If a layout shifts on mobile or a user is blind, these directional hints break down.
4. Review Issues (Review all by April 2027)

Review Issues (Review all by April 2027)

Unlike the previous issues—which are automated code errors—these are architectural and media governance issues. They flag pages that host heavy downloads, third-party embedded media, or unmanaged external files that often violate WCAG compliance unless carefully audited.

1. High-Density Downloads & Heavy Pages

Pages with a massive concentration of external files or media slow down loading times and can be overwhelming to navigate with assistive tech.

  • Archive Review – 10+ PDFs on a page: Having over ten PDF files listed on a single page creates significant navigation hurdles. PDFs are notoriously difficult to make fully accessible, and having this many on one page usually indicates a need for a dedicated document library, filtering system, or web-based content instead.
  • Archive Review – 5+ videos on a page: Loading five or more video players on a single page heavily impacts performance, mobile data, and page speed. It also creates a clutter of video controls for keyboard and screen reader users.

Linking directly to Google Drive files creates privacy, permissions, and compliance risks for affiliated organizations.

Links to Documents / Files / Presentations / Spreadsheets in Google Drive:

  • Access Barriers: Drive links frequently break due to permission errors (“Request Access” screens).
  • Inconsistent Experience: Drive opens files in a web app interface that isn’t optimized for all screen readers, rather than letting the user view clean HTML on your site or download a standard file.
  • Best Practice: Convert Google Docs/Sheets into standard, accessible web pages on your site, or host official, tagged downloadable files on your web server rather than linking to personal or organization Drive accounts.

3. PDF Compliance Risks

Archive Review – PDF Documents: PDFs must adhere to WCAG standards (proper tag structure, reading order, alt text for images inside the PDF, and form labels). Because PDFs are rarely created accessibly by default, every linked PDF requires a manual audit or conversion into a native web page.

4. Embedded Media & Third-Party Players

Videos and audio players must be accessible to users who are deaf, hard of hearing, blind, or have low vision.

Embedded Audio / Embedded Video: Any audio or video file hosted on the page must provide:

  • Captions (for video): Accurate, synchronized closed captions for deaf or hard-of-hearing users.
  • Transcripts (for audio & video): Full text transcripts available directly on the page.
  • Audio Descriptions: Descriptions of key visual actions for users who are blind or low-vision.
  • Keyboard Controls: Media controls (play, pause, volume, scrub) must be fully operable using only the Tab and Spacebar keys.

Embedded YouTube / Vimeo Videos: Third-party iframe embeds must include an accessible title attribute on the iframe itself (e.g., title=”Product Overview Video”) so screen readers can identify what the video player is before the user interacts with it.

Need a Custom Report?

Contact the Web Accessibility Team at OITAccessibility@BoiseState.edu to discuss options available for a custom report.