Boston University Minimum Web Accessibility Standards
Under the University’s Website Policy (the “Policy”), all new and redesigned University Websites and Web-enabled content published after the Policy’s Effective Date must comply with these Minimum Web Accessibility Standards (MWAS). The MWAS articulate the minimum technical and visual requirements needed to comply with the Policy’s accessibility requirements for University Websites and Web-enabled content. Capitalized terms used in the MWAS but not defined have the meanings given in the Policy.
BU MWAS are based on Web Content Accessibility Guidelines (WCAG) 2.0 Level AA published by the World Wide Web Consortium and are intended to address the following four accessibility principles:
4 Core Principles
-
Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
-
Operable
User interface components and navigation must be operable.
-
Understandable
Information and the operation of user interface must be understandable.
-
Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Covered Groups
The goal of the MWAS is to make content delivered on a University Website or Web-Enabled accessible content perceivable, operable, understandable and robust (as further described in the WCAG guidelines) to persons with disabilities, including persons with any of the following disabilities:
Visual Impairments
Visitors with blindness and other severe visual impairments typically use screen-reading software to access web content. Visitors with low vision may use additional methods such as enlarging screen fonts, software magnification of the screen, and/or enabling high-contrast display.
Color Blindness
Visitors with a color blindness may have difficulty distinguishing between certain color combinations, different shades of the same color, or may be unable to read text that contrasts poorly with a background color.
Deafness or Hard of Hearing
Visitors with audio impairments rely on text transcripts and other alternatives to audio content.
Motor Disabilities
Visitors may have difficulty or the inability to use pointing/clicking devices due to disease, injury, and/or congenital conditions. This can impact response times and navigation within web forms and page controllers.
Cognitive Disabilities
Visitors may have learning disabilities, conditions affecting reading comprehension, attention deficit and distractibility disorders, problems with memory and retention, and related conditions.
Compliance Guidelines
MWAS was developed by Information Services & Technology in collaboration with Marketing & Communications, Office of Disability Services, and the Office of General Counsel. MWAS will be reviewed and updated in accordance with the schedule outlined in the Web Accessibility Policy.
The guidelines are structured by compliance checkpoints. Each checkpoint is an item to consider when reviewing your content for accessibility.
Required elements must be implemented to maintain the MWAS.
Recommended elements should be considered and implemented as possible and/or when appropriate.
If you see this icon it means the following web accessibility standards are supported by Boston University’s Responsive Framework!
Checkpoint 1: Text Alternatives
Provide text alternatives for any non-text content so that it conveys the equivalent meaning/purpose of the non-text content.
Required: Use the alt attribute of the HTML image tag to provide a description of images when the image presents additional content that is not fully represented by surrounding text in the page. Describe the meaning of the image and what it conveys to your visual visitors. This is especially important for images that convey information, such as infographics.
Required: Use a blank alt attribute for graphics/images that are purely decorative.
Required: When using a graphic as a link, use the alt attribute to indicate the link target.
Recommended: Use CSS for decorative elements rather than inline images.
A great resource for when you should — or should not — include the alt text is the Alt Text Decision Tree.
For BU WordPress editors: the “Alt Text” dialogue box associated with your photo/image in the WordPress Media Library is the alt attribute for accessibility purposes.
WCAG 2.0 Reference: Guideline 1.1
Checkpoint 2: Multimedia Captions and Transcripts
Provide captions and/or transcripts for pre-recorded audio and video content.
Required: Full-text, verbatim, captions that are synchronized with the presentation should be provided for all video content. Captions should identify when sound effects or audio cues are used, where appropriate.
Required: Full-text, verbatim transcripts are provided for audio recordings. Transcripts should identify when sound effects or audio cues are used, where appropriate.
Required: Video or audio content does not “autoplay” on page load. Purely decorative and/or background videos are exempt from this requirement.
Recommended: Provide a second, user-selectable, audio track that includes audio descriptions of video content.
WCAG 2.0 Reference: Guideline 1.2
Checkpoint 3: Content Organized Independent of Style
Create content that does not lose information or structure when style and presentational elements are removed.
Required: Content needs to convey the same meaning and maintain the same structure if stylesheets are disabled.
Required: Properly nested HTML headings (h1, h2, h3, etc.) and semantic HTML elements should be used throughout. Lists should be marked up in HTML as lists. Paragraphs as paragraphs. Blockquotes as blockquotes. Etc.
Required: Pages use a title element in the head of the document. (This is included by default in BU Responsive Framework WordPress theme.)
Recommended: Primary site navigation menus should use HTML unordered lists. (This is included by default in BU Responsive Framework WordPress theme.)
Recommended: Pages use a language attribute in the body element. (This is included by default in BU Responsive Framework WordPress theme.)
Recommended: Content sections are identified using ARIA landmark roles. (This is included by default in BU Responsive Framework WordPress theme.)
Recommended: Tab order through page elements corresponds with the visual display order. (This is included by default in BU Responsive Framework WordPress theme.)
WCAG 2.0 Reference: Guideline 1.3
Checkpoint 4: Conveying Information with Color
Any information conveyed with color must also be available without color.
Required: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Recommended: Web editors should avoid color combinations that may impair usability for visitors with common forms of color blindnesses.
WCAG 2.0 Reference: Guideline 1.4.1
Checkpoint 5: Sufficient Contrast for Color Combinations
Content must be displayed with sufficient color contrast for those visitors with low-vision or color deficits, and must be fully functional when viewed in grayscale (black & white screen).
Required: The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 for content body type, and 3:1 for large text (e.g. headings). Color contrast for non-essential meta data (author, date, categories, etc.) is exempt from the contrast ratios.
Resource: Color Contrast Checker. This tool provides pass/fail assessment against WCAG 2.0 color contrast guidelines.
WCAG 2.0 Reference: Guideline 1.4.3
Checkpoint 6: Resizable Text
Text must be resizable and must not require horizontal scrolling.
Required: Text can be resized by the user without assistive technology up to 200 percent without loss of content or functionality. (This is included by default in BU Responsive Framework WordPress theme.)
WCAG 2.0 Reference: Guideline 1.4.4
Checkpoint 7: HTML Tables
It’s recommended to use HTML tables only for tabular data. Avoid using HTML tables for layout purposes. When implementing HTML tables use row and column headers, and associate data cells with header cells on complex tables.
Required: Identify row and column headers with the th tag.
Recommended: Do not use HTML tables for page or content layout.
Recommended: Use the summary attribute to explain the purpose and structure of the table.
Recommended: Use the caption element to provide a descriptive title of the table.
Required: Simple HTML tables (tabular data) have scope (row or col) set on table header cells.
Recommended: Complex HTML tables (those with multiple rows, column spans, etc.) use headers and id attributes to associate data cells with header cells.
WCAG 2.0 Reference: Guideline 1.3.2
Checkpoint 8: Frames / iframes
Frames or iframes (in-line frames) should be titled for help with identification and navigation.
Required: Frames/iframes use the title attribute identifying their purpose and describing their content.
Recommended: Do not use hidden frames or hidden iframes.
Recommended: Use CSS or iframes (in-line frames) rather than standard HTML frames.
WCAG 2.0 Reference: Guideline 1.3
Checkpoint 9: Keyboard Navigation and Focus
Not all visitors can use a mouse, touchpad, or other point-and-click device. Make all functionality available from a keyboard.
Required: Visitors must be able to move focus on the page using a keyboard interface, typically using arrow or tab keys. (This is included by default in BU Responsive Framework WordPress theme.)
Required: If keyboard navigation requires more than unmodified arrow or tab keys or other standard methods, the visitor is advised of the method for moving focus.
Required: Web-based forms must support assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. (Standard forms created with the forms plugin and BU Responsive Framework WordPress theme meet accessibility guidelines.)
Recommended: Ensure tab order for web-based forms moves the visitor through the form in a logical manner (e.g. first name followed by last name; field labels correspond to their form elements, etc.)
WCAG 2.0 Reference: Guideline 2.1
Checkpoint 10: Seizures
Pages should be designed to avoid causing the screen to flash more than three times in any one second. Flashing content at certain frequencies is known to cause seizures in some individuals.
Required: Do not publish content that flashes 3 times or more in any one second, or the flash is below the general flash and red flash thresholds.
WCAG 2.0 Reference: Guideline 2.3
Checkpoint 11: Navigation and Wayfinding
Provide a method for visitors to skip over long lists of links, such as primary content navigation menus. Clearly identify link targets and inform the user when links open in pop-ups or new windows.
Required: Provide a way for users to skip repetitive link lists (e.g. “skip to page content”).
Required: Styles should accommodate clear visibility of the keyboard focus indicator. (This is included by default in BU Responsive Framework WordPress theme.)
Required: Do not use styles to remove the underline from text links unless there is another way of visually distinguishing clickable text without relying solely on text color.
Required: Do not use “click here” or “here” for link text. Identify the target of each link, preferably within the context of the link language itself.
Required: To accommodate users of touch devices, navigation icons/buttons must use a minimum touch-target size of 48 pixels x 48 pixels.
Recommended: Use ARIA landmark roles. (This is included by default in BU Responsive Framework WordPress theme.)
Recommended: Do not change the active window without informing the user.
WCAG 2.0 Reference: Guideline 2.4
Checkpoint 12: Adequate Time for Tasks.
Ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit.
Required: When a time limit is set by content, provide visitors with at least one of following mechanisms:
- Visitor is allowed to turn off the time limit.
- Visitor can adjust the time limit.
- Visitor is given an accessible mechanism to extend the time limit when the limit is reached.
- Exceptions: real-time events (e.g. online auction) and activities where the time limit is an essential function.
Required: Do not used timed server redirects.
WCAG 2.0 Reference: Guideline 2.2
Checkpoint 13: An Understandable User Experience
Content and information plus the operation of user interface must be understandable. Pages should appear and operate in predictable ways.
Required: The language of the page and language of the content can be programmatically determined. (This is included by default in BU Responsive Framework WordPress theme for pages published in the English language; editors of sites using non-English languages can configure custom meta tags to define the native language for their pages.)
Required: Navigational mechanisms that are repeated on multiple pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (This is included by default in BU Responsive Framework WordPress theme.)
WCAG 2.0 Reference: Guidelines 3.1, 3.2
Checkpoint 14: Best Practices and Standards Compliance
Follow web best practices and use standards-compliant markup for all content.
Required: All user interface components (including form elements, links and components generated by scripts) can be programmatically determined by assistive technologies. (This is included by default in BU Responsive Framework WordPress theme.)
Required: When using hand-crafted HTML ensure all elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique.
Required: Provide error feedback for web-based forms (e.g. when a required field is missing, alert the user in a manner consumable by assistive technologies).
Recommended: Use an accessible publishing system (e.g. BU Responsive Framework WordPress theme) and use hand-crafted HTML responsibly and work with professionally-trained web developers experienced with accessibility concerns.
WCAG 2.0 Reference: Guidelines 3.3, 4.1
Last Resort
An accessible alternate page (e.g. text-only, non-Flash, non-dynamic, etc.) mirroring equivalent information or functionality, can be provided to make a web site comply with this policy, when compliance cannot be accomplished in any other way. The content of mirror pages must be updated every time the primary page changes. Separate, up-to-date, accessible “mirror pages” are used only as a last resort.
