Microsite Accessibility Requirements

1. Introduction #

Purpose #

This document defines the accessibility requirements for all microsites affiliated with Gallaudet University. Any web property that uses the Gallaudet brand, is hosted under gallaudet.edu, or represents a Gallaudet department, program, or initiative must meet these standards.

Who This Is For #

• Department web teams managing their own sites
• External vendors and agencies building on behalf of Gallaudet
• Content editors publishing pages, posts, and media

Compliance Standard #

All microsites must conform to WCAG 2.2 Level AA. This is not optional — it is a legal requirement under Section 504 and Section 508 of the Rehabilitation Act, and aligns with Gallaudet’s mission as a university for deaf and hard of hearing students.

---

2. Brand Color Contrast Reference #

Color contrast is one of the most common accessibility failures. The following reference provides pre-calculated contrast ratios for all primary brand colors so you do not need to check them individually.

Approved Text Color Pairings #

Use these combinations for body text, headings, and links. All meet WCAG AA (4.5:1 for normal text, 3:1 for large text).

Prohibited Color Pairings #

These combinations fail WCAG AA and must never be used:

Rule of thumb: If a color looks “light” or “muted,” do not use it for text. Light colors are only acceptable as background fills or decorative elements.

Non-Text Contrast (Borders, Icons, UI Components) #

Interactive UI components (form borders, icon buttons, focus indicators) require a minimum 3:1 contrast ratio against their adjacent background.

Logo Usage #

• Dark backgrounds: Use the white/light version of the primary Gallaudet University logo
• Light backgrounds: Use the dark/blue version of the primary Gallaudet University logo
• Minimum size: The logo must remain legible at its displayed size. Do not scale below 60px width on desktop or 40px on mobile.
• Clear space: Maintain adequate padding around the logo so it is not visually crowded
• Never place the logo on a background where the contrast between the logo and background is below 3:1

---

3. Content Accessibility Requirements #

Images #

• Every meaningful image must have descriptive alt text. Describe what the image shows and why it matters in context. Keep it under 150 characters.
• Decorative images (backgrounds, spacers, visual flourishes) must use alt="" so screen readers skip them.
• Images of text should be avoided. Use real HTML text instead. If an image of text is unavoidable, the alt text must contain the full text shown in the image.
• Complex images (charts, infographics, diagrams) need a longer description either in surrounding text or via a linked description page.

Headings #

• Use one <h1> per page — this is the page title.
• Headings must follow a logical hierarchy: <h1> then <h2> then <h3>. Never skip levels (e.g., jumping from <h2> to <h4>).
• Do not use headings for visual styling. If you need large bold text that is not a section heading, use CSS classes instead.
• Every major section of content should begin with a heading.

Links #

• Link text must describe the destination. “Read more about undergraduate admissions” is accessible. “Click here” or “Read more” alone is not.
• If multiple links on the same page share identical text (e.g., multiple “Learn More” links), each must be distinguishable. Use aria-label to provide unique context: aria-label="Learn more about Biology program".
• Links must be visually distinguishable from surrounding text — use color plus underline, or color plus another visual indicator (not color alone).

Video and Audio #

• All video content must have captions. This includes YouTube embeds, Vimeo, and self-hosted video. Auto-generated captions must be reviewed and corrected.
• ASL videos must include a text transcript below or adjacent to the video. Use a collapsible accordion if the transcript is long.
• Audio-only content (podcasts, recordings) must have a text transcript.
• Video iframes must include a descriptive title attribute. Use the video title or a description of the content — not “YouTube video player.”

Documents #

• PDFs must be tagged and accessible. An untagged PDF is invisible to screen readers. Use Adobe Acrobat’s Accessibility Checker before publishing.
• Prefer HTML content over PDFs whenever possible. HTML is inherently more accessible, responsive, and searchable.
• Word documents, PowerPoint, and Excel files should follow their respective accessibility checkers (built into Microsoft Office).

---

4. Interactive Component Requirements #

Forms #

• Every form input must have a visible <label> element programmatically associated with the input using for/id attributes.
• Placeholder text is not a substitute for a label. Placeholders disappear on focus and are not reliably announced by screen readers.
• Required fields must be indicated by more than just color (e.g., an asterisk with “(required)” text).
• Error messages must appear adjacent to the field they relate to and be programmatically associated using aria-describedby.
• Form submission errors must be summarized at the top of the form with links to each invalid field.

Buttons vs. Links #

• Use <button> for actions (submit, toggle, open/close, delete).
• Use <a href> for navigation (going to another page or section).
• Never use <div>, <span>, or <a> withouthrefas clickable elements. These are not keyboard accessible or announced correctly by screen readers.

Focus Indicators #

• All interactive elements must show a visible focus ring when navigated to via keyboard. This applies to links, buttons, inputs, selects, checkboxes, and any custom interactive component.
• Never suppress focus outlines with outline: none or outline: 0 unless you are replacing them with an equally visible custom indicator.
• Recommended focus style: outline: 2px solid #0C365A; outline-offset: 2px; — this is the Gallaudet standard.
• Use :focus-visible (not :focus) to avoid showing outlines on mouse clicks while ensuring they appear on keyboard navigation.

Modals and Popups #

• Focus must move into the modal when it opens — typically to the first focusable element or the close button.
• Focus must be trapped inside the modal while it is open. Pressing Tab should cycle through modal content only.
• Pressing Escape must close the modal.
• Focus must return to the element that triggered the modal when it closes.
• Modals must have role="dialog" and aria-modal="true" and a label via aria-labelledby pointing to the modal’s heading.

Carousels and Sliders #

• Must include a visible pause/play button if the carousel auto-advances.
• Must not auto-advance when the user has enabled “Reduce Motion” in their operating system settings.
• Navigation controls (previous/next, slide indicators) must be keyboard accessible with descriptive labels.
• Carousel containers should use role="region" and aria-roledescription="carousel" with a descriptive aria-label.

Accordions and Tabs #

• Accordion triggers must be <button> elements inside heading elements, with aria-expanded indicating open/closed state and aria-controls pointing to the content panel.
• Tab interfaces must use role="tablist", role="tab", and role="tabpanel" with aria-selected on the active tab and aria-controls/aria-labelledby relationships.

---

5. Technical Requirements #

Semantic HTML #

Use proper HTML elements for their intended purpose:

ARIA #

• Use ARIA only when native HTML semantics are insufficient. A <button> does not need role="button".
• Label all landmark regions if there are multiple of the same type (e.g., two <nav> elements should have distinct aria-label values).
• Never use aria-hidden="true" on visible, interactive content. It hides the element from screen readers.

Target Size (SC 2.5.8) #

• All clickable/tappable elements must have a minimum target area of 24 x 24 CSS pixels.
• This includes: buttons, links, checkboxes, radio buttons, icon buttons, carousel indicators, pagination controls, close buttons, and any custom interactive element.
• Inline links within paragraphs of text are exempt, but standalone interactive elements are not.

Motion and Animation (SC 2.3.3) #

• Respect prefers-reduced-motion**.** When a user has enabled reduced motion in their OS settings, all animations, transitions, auto-advancing carousels, and smooth scrolling must be disabled or reduced to instant.
• No content may flash more than 3 times per second.
• Auto-playing video or animation must have a pause mechanism.

Consistent Help (SC 3.2.6) #

• If your microsite includes help mechanisms (search bar, contact links, phone numbers, FAQ links), they must appear in the same relative position on every page.
• The recommended pattern: search in the header, contact information in the footer.

Page Structure #

• Every page must have a skip link as the first focusable element: “Skip to main content.”
• Every page must have exactly one <h1> that describes the page content.
• The page <title> must be unique and descriptive (e.g., “Undergraduate Admissions | Gallaudet University” — not just “Home”).
• The page language must be declared: <html lang="en">.

---

6. Recommended Tools #

All of the following tools are free and sufficient for verifying compliance.

Contrast Checking #

Automated Page Auditing #

Screen Reader Testing #

Keyboard Testing #

No tool needed — just unplug your mouse and navigate the entire site using only:

What to look for: Can you reach every interactive element? Can you see where focus is at all times? Can you operate every control? Can you escape from every modal/popup?

---

7. Testing Checklist #

Use this checklist before launching or updating any page. Every item should pass.

Visual #

• All text meets 4.5:1 contrast ratio against its background (3:1 for large text)
• All UI component borders and icons meet 3:1 contrast ratio
• Page is usable at 200% browser zoom with no horizontal scrolling or content loss
• No information is conveyed by color alone (always pair with text, icons, or patterns)

Keyboard #

• Every interactive element is reachable via Tab key
• Every interactive element shows a visible focus indicator
• Modals trap focus and close with Escape
• Focus order follows logical reading order
• Skip link is present and functional

Screen Reader #

• Page has one <h1> and headings follow logical order
• All images have appropriate alt text
• All form inputs have associated labels
• All landmarks are present and uniquely labeled
• All links have descriptive text

Media #

• All videos have accurate captions
• All ASL videos have text transcripts
• All audio content has text transcripts
• Video iframes have descriptive title attributes

Motion #

• Animations are disabled when “Reduce Motion” is enabled in OS settings
• Auto-advancing carousels have a pause button
• No content flashes more than 3 times per second

Components #

• All clickable elements are at least 24x24px
• Accordions use proper ARIA (aria-expanded, aria-controls)
• Tabs use proper ARIA (role=“tablist”, role=“tab”, aria-selected)
• Forms show accessible error messages on validation failure

---

8. Compliance and Review Process #

Before Launch #

All new microsites or major redesigns must pass an accessibility review before going live. To request a review:

• Complete the testing checklist above and fix any issues you find
• Create a web team ticket at gu.live/request with:
  • URL of the staging/preview site
  • Description of the site’s purpose and audience
  • Any known issues you were unable to resolve
• Allow 5 business days for the initial review

Ongoing Compliance #

• Content updates (new pages, posts, media) are the responsibility of the department managing the microsite. Follow this document for every piece of content published.
• Structural changes (new templates, layouts, functionality) should be reviewed by the web team before deployment.
• Annual audit: The web team will conduct an annual accessibility audit of active microsites and provide a remediation report.

Remediation Expectations #

• Critical issues (no keyboard access, missing form labels, no video captions): Fix within 5 business days
• Major issues (contrast failures, missing alt text, heading hierarchy problems): Fix within 15 business days
• Minor issues (target size slightly below 24px, missing aria-label on one element): Fix within 30 business days

Questions and Support #

For accessibility questions, guidance, or to report an issue:

• gu.live/request
• Documentation: WCAG 2.2 specification at w3.org/TR/WCAG22
• Training: Contact the web team to schedule an accessibility training session for your department