The MBTA intranet system is an internal application for MBTA employees

This system enables MBTA employees to communicate with each other, find and share information, and fulfill job tasks.

The system includes features such as discussion forums, surveys, directories, content management, and analytics.

The accessibility audit which we performed identified areas where the system could introduce barriers or cause difficulty for people with disabilities.

• Access the intranet system via web browser using user accounts provided by the MBTA team.
• Test selection of 41 pages and use cases (AKA tasks), as identified by the client
• Use W3C’s Web Content Accessibility Guidelines (WCAG 2.1) Level AA as a guide for this evaluation.
• Explore all areas of the screen, including the menus, forms, and other components, to ensure a complete accessibility review.

• Homepage
• GM COVID-19 Video Update 10
• COVID-19 Face Covering Policy: Medical Exemption Guidance
• Employee Center Homepage
• Between the Lines – Fall 2019
• Employee Directory
• Employee Profile
• Training Video
• Google Example Link Page
• Poll Example

• Chrome’s Accessibility Dev tools auditor - Lighthouse
• JAWS - Screen Reader
• Dragon Naturally Speaking - Speech Recognition Software
• Color Contrast evaluation tool
• Keyboard only evaluation
• Chrome’s Accessibility Dev tools auditor - Lighthouse.
• Google Chrome, MS Internet Explorer, Mozilla Firefox - Browsers

Subjective ratings are based on three factors:

• The likelihood that a given issue will prevent users from completing a task
• The criticality of the task affected by said issue
• Short of preventing task completion, the extent to which the issue will cause frustration and confusion among users

Ratings:

• Severity Level: 3 Likely to prevent a user’s completion of a critical task
• Severity Level: 2 Likely to prevent a user’s completion of a non-critical task OR likely to cause confusion or frustration and have a significantly negative impact on, but not prevent, a user’s completion of a critical task
• Severity Level: 1 Potential to cause minor confusion or frustration and negatively affect (e.g., slow down), but not prevent, a user’s completion of a task

Accessibility was taken into consideration during the design and development of MBTA's intranet site.

Structure and organization of pages across the system was generally consistent.

Skip links were implemented on the website.

Images not associated with properly descriptive alternative text

WCAG Guideline 1.1 - Text Alternatives

These images next to text were not associated with alt text

Recommendation

Ensure that all meaningful images are assigned descriptive alt text. If the image is not meaningful or vital to user understanding, hide the image from assistive technologies by using null text

Interactive buttons/links/controls not associated with properly descriptive labels

WCAG Guideline 1.1 Text Alternatives
WCAG Guideline 3.2 Predictable
WCAG Guideline 3.3.2 Labels or Instructions

Only hyperlinked "MBTA Admin" text announced by the screen reader

Recommendation

Ensure that all interactive elements (buttons, links, controls, etc.) have appropriate and descriptive programmatic labels that alert blind users about the purpose/function of said interactions. For instance, include native text within <a> tags that is visually hidden using CSS. Or include ARIA labels that describe interactive elements without affecting the visual design of the content

Keyboard focus not automatically set to newly-surfaced content

WCAG Guideline 2.1.1 Keyboard
WCAG Guideline 3.2.2 On Input

Focus does not shift to the overlaying panel

Recommendation

Ensure that when new content appears on a page in response to user input, focus shifts to it automatically. This will help users with visual impairment to recognize that new content has appeared, and access it immediately if desired.

Interactive elements accessible via mouse but not keyboard

WCAG Guideline 2.1 Keyboard Accessible
WCAG Guideline 4.1.2 Name, Role, Value

Some interactive elements can be selected with the mouse, but *cannot* be accessed via the keyboard and/or speech recognition tools (e.g. Dragon)

Recommendation

• Ensuring that the element is implemented via natively interactive HTML element in the markup (e.g. <a>, <button>, etc), rather than with elements not intended to be interactive in the HTML spec (e.g. <li>, <span>, etc.)
• Ensuring that any native link (<a>) elements are assigned an 'href' attribute with a non-null value (e.g. a proper URL, a "#" value, or even "javascript:void(0)")
• (As a last resort) For non-natively interactive elements that are forced to be interactive, adding the tabindex attribute with a value of either zero, or some positive integer.

Keyboard focus indicator missing for nearly all interactive elements

WCAG Guideline 1.4 Distinguishable
WCAG Guideline 2.4.7 Focus Visible

Currently, across the MBTA intranet system, a visible focus indicator is missing for nearly all interactive elements disabled entirely using ("outline: none")

Recommendation

• Avoid overriding browsers’ default focus indicator
• Ensure that all interactive elements have a clearly visible focus indicator that show keyboard users where they are currently located in the tab order
• Use a CSS style for focus *:focus{outline: 2px dashed #0079CB !important;}

Radio buttons inaccessible via keyboard and speech recognition.

WCAG Guideline 2.1 Keyboard Accessible
WCAG Guideline 4.1.2 Name, Role, Value

Inaccessible radio button inputs on the Home page poll

Recommendation

• Best practice is to use native/semantically accurate HTML elements to accomplish the tasks they were intended for in the HTML spec, and to not override their default behavior
• In this case, use the radio type <input>s for their intended purpose, and don't hide them from assistive technologies with "display:none" instead have opacity changed to 0

Hidden content still receives keyboard focus and/or remains in the reading order

WCAG Guideline 2.4.3 Focus Order WCAG Guideline 3.2 Predictable

Administration links in the left nav that remain in the tab order when hidden

Recommendation

• Ensure to take hidden/off-screen elements out of focus order
• For example, use 'tabindex="-1"' to remove an element from the DOM when it's hidden

Videos not accompanied by programmatic text captions

WCAG Guideline 1.2.2 Captions

An example of a training video without captions, users who are deaf or hard of hearing will not be able to benefit from them.

Recommendation

• Provide an alternative text presentation of the video content on the web page
• Add captions to the video that include dialogue and meaningful sound effects

Tooltips only visible via hover and not announced by screen reader.

WCAG Guideline 1.4.13 Content on Hover or Focus WCAG Guideline 2.1 Keyboard Accessible WCAG Guideline 2.4.6 Headings and Labels

The Watch link has a tooltip, screen-reader users cannot access the information in it

Recommendation

Ensure that the tooltip is accessible using keyboard focus and users can dismiss it by pressing the "Escape" key.
Also make the two following semantic additions:

• Associate the tooltip trigger with the tooltip via 'aria-describedby' and id
• Ensure the tooltip is unreachable when hidden via aria-hidden

Important content is hidden on zoom or reduced screen width

WCAG Guideline 1.4.13 Content on Hover or Focus
WCAG Guideline 2.1 Keyboard Accessible
WCAG Guideline 2.4.6 Headings and Labels

The missing "New Event" button at increased page zoom due to 'display: none' CSS property.

Recommendation

Ensure that these buttons and links are visible and accessible in all viewports

Important content is hidden on zoom or reduced screen width

WCAG Guideline 1.4.10 Reflow

"Search" field width was reduced when screen width is 320px

Recommendation

Increase the input element width on lower screen widths and increased zoom levels

Color Contrast Issues