Page D.

WCAG 2.1 is an internationally-recognized set of guidelines from the World Wide Web Consortium (W3C) for making web content accessible to people with disabilities (visual, auditory, motor, cognitive) across devices (desktop, mobile, tablet). W3C+2W3C+2

Level AA is the “mid-tier” conformance level (above A, below AAA), and is widely considered the practical target for accessibility compliance. UserWay+2Accessible Web+2

WCAG 2.1 builds on WCAG 2.0 (so everything in 2.0 still applies) and adds additional criteria to address newer tech, mobile devices, low-vision, cognitive/learning disabilities. WCAG+2W3C+2

Good contrast between text and background so users with low vision can read. (e.g., “non-text contrast” and “text spacing” are new criteria in 2.1 at AA level) Level Access

Reflow: content should adapt to different screen sizes without requiring horizontal scrolling (important for mobile) Level Access+1

Meaningful labels and clear navigation so users can find & understand content, and consistent navigation across pages. theappbusiness.github.io+1

Keyboard accessibility – everything should work without a mouse (important for motor/mobility issues). Accessible.org+1

Identify input purpose (for form fields) so assistive tech can help. W3C+1

The website/app should not impose unnatural lock-in (e.g., locked orientation) unless absolutely necessary. W3C+1

Provide text alternatives for all non-text content (images, icons, charts). Users of assistive tech like screen-readers must get meaningful alternative text.

Ensure color contrast between text and background meets the minimum ratio required for Level AA (e.g., 4.5:1 for normal text).

Support reflow: when zoomed or viewed on narrow/mobile screens, content should remain readable without horizontal scrolling. (WCAG 2.1 adds mobile & low-vision support.)

Provide captions and/or transcripts for multimedia (videos embedded in presentations) so auditory information is accessible to those who are deaf or hard of hearing.

Ensure that meaning is not conveyed by color alone — e.g., if the AI generated layout uses color to distinguish items, there must also be other visual cues.

Full keyboard accessibility: All UI controls (creating slides, navigating cards, presenting mode) must be reachable and operable via keyboard alone.

No keyboard traps: Users should be able to move focus away from any interactive element easily.

Provide visible focus indicators (highlighting which element is selected) so keyboard users can see where they are.

Allow content to be paused, stopped or hidden (for animations or auto-advancing cards) so users with cognitive or motor impairments aren’t forced into motion they can’t control.

Ensure presentation mode supports navigation via arrow keys (or keyboard equivalents), and users with assistive tech can get consistent behaviour. (Gamma already supports left/right arrow keys in “Present Mode” for card navigation). Gamma Help Center+1

Clear and consistent navigation: The layout of cards and controls should remain consistent across the tool (and generated decks) so users learn the pattern.

Language and instructions: UI must specify the language of the text, avoid jargon, and provide ability to switch language or indicate changes.

Predictable behaviour: When the AI “regenerates” a layout, or a theme is changed, the result should not confuse navigation or readability (for example, moving cards unexpectedly, changing reading order).

Error prevention and correction: If a user uploads content (e.g., a PDF) and the AI fails to convert it cleanly, there should be clear instructions or fallback to allow editing.

Ensure compatibility with current and future user agents — e.g., screen-readers (NVDA, JAWS), browsers, mobile devices.

Provide semantic HTML markup (or equivalent) so assistive technologies can parse structure (headings, tables, lists) properly.

When exporting (PDF, PPTX, Google Slides) ensure that exported files preserve accessibility features (alt-text, semantic structure) so recipients who use view/edit in other tools are still served.

Validate that every AI-generated card includes accessible markup: heading levels (H1, H2…), alt text on visuals, logical reading order.

In “Present Mode”, ensure the spotlight feature doesn’t remove focus or hide content from screen-reader users. For example, when dimming or fading cards, check that they remain perceivable.

The drag/drop editor must still allow keyboard users to reorder cards.

Exports: When users export to PPTX or Google Slides, verify that alt-text and layout are preserved (not just visual appearance).

Theme switching: When users change to a new theme, ensure that the color contrast remains sufficient (i.e., the AI doesn’t pick a low-contrast color scheme).

Mobile/web responsiveness: Since Gamma can be used via browser (no dedicated mobile app) Gamma Help Center, ensure that when used on mobile, the cards stack and zoom appropriately, and no horizontal scroll is required up to 400 % zoom for low-vision users.

Keyboard navigation during live presentation: Confirm arrow keys, Enter/Space, and Escape work for all major functions (advance slide, open nested cards/toggles) as referenced in Gamma’s help documentation. Gamma Help Center+1

Provide clearly labelled UI controls, including for assistive tech: e.g., “Generate presentation”, “Insert card”, “Export”, “Share link”.

Offer an option for users to review AI-generated content for meaningfulness and accessibility (for example, ensure images match alt text, avoid placeholder text like “Image description”).

Document accessibility features and provide help/tooltip for users about using the platform with screen-readers (for example aligning their preference for NVDA, since you noted preference for NVDA in your profile).

Ensure that interactive content (embedded media, toggles) is fully accessible: keyboard operable, screen-reader labelled, and doesn’t rely solely on gesture or hover.