Let's break some WCAG rules - Elise Kristiansen - NDC Copenhagen 2026

Main ideas, concepts, and lessons

• Accessibility is a developer responsibility: When accessibility is ignored, developers effectively exclude people from using products that could otherwise be inclusive.
• WCAG is the framework: The talk uses WCAG (Web Content Accessibility Guidelines) to explain what “accessible” means for different kinds of users.
• Accessibility benefits everyone: The speaker emphasizes that issues like contrast, clear headings/labels, keyboard navigation, and visible focus improve usability not only for people with disabilities, but for many users in real-world conditions.
• Common mistakes come from incorrect implementation choices:
  • Using the wrong HTML elements (often overusing div and onclick)
  • Missing or incorrect semantics (headings, labels, roles)
  • Poor contrast or relying on color alone
  • Missing language metadata
  • Motion/distraction problems (timing, blinking, scrolling, flashing)
  • Form labeling problems
  • Using icons without text context
  • Video accessibility omissions (captions, sign language)

---

Methodologies / instructions presented

WCAG basics and goals (what to target)

• Use WCAG levels as a guide
  • Level A: Avoid complete barriers (e.g., keyboard navigation support, alt text, not relying only on color)
  • Level AA: Legal requirement in the EU Accessibility Act (aim for this at minimum)
  • Level AAA: Highest target (e.g., sign-language interpretation, simpler language, stricter contrast)
• Aim to meet contrast requirements
  • The speaker notes:
    • AA is “good enough” for many cases
    • AAA requires stronger contrast, especially for small text
  • Practical guidance given:
    • Increase contrast (example mentioned: background/contrast tuned from a ~6.27:1 style toward ~9.4x+:1) to reach higher accessibility targets.

Non-text content (images/icons)

• All meaningful images must have appropriate alternative text
  • Provide alt text so screen reader users don’t experience an “empty/black box.”
• Alt text must include context, not just description
  • Don’t just say “a cat and a bird”; describe why the image is there (e.g., “a cat hunting a bird” depending on the article topic).
• Icons must not be used without text context
  • Don’t rely on the icon alone to communicate destination/purpose.
  • Include visible text (or an accessible label) describing what the icon link does (not just what the icon depicts).
  • Rationale: users can have different associations with icons.

Structure with headings and correct HTML semantics

• Use correct HTML tags instead of generic containers
  • Instruction repeated throughout: avoid using div for everything; use proper semantic elements.
• Heading rules (structure for screen readers)
  • Every page should have:
    • At least one H1
    • Only one H1 as the main page title
  • Heading progression:
    • Use H2 for new sections/themes under the H1
    • Use H3 for subsections under H2
    • Continue logically as needed (H4/H5/H6 if truly appropriate)
  • Don’t use heading number changes for styling; the numbering should reflect document structure.

Color and contrast

• Meet contrast ratios (AA first, then consider AAA)
  • The talk contrasts requirements:
    • AA: about 3:1 for large text and 4.5:1 for small text
    • AAA: about 4.5:1 for large text and 7:1 for small text
• Do not use color as the only way to convey meaning
  • Color perception varies (including color blindness), and grayscale can reduce readability.
  • Therefore:
    • Ensure information is available through text/structure, not color alone.

Language metadata

• Set the correct language for the page
  • Use the lang attribute so screen readers read with correct pronunciation/voice.
• Support language changes within the same page
  • For sections in another language/region, set lang on those sections too.
  • This enables screen readers to switch language appropriately.

Keyboard accessibility and motor impairments

• Ensure full keyboard operability
  • Keyboard users should be able to navigate to interactive elements (no mouse-only controls).
• Use correct focus order
  • The speaker’s instruction: ensure “back then next” (example), meaning DOM order/semantics must match intended navigation order.
  • Warns against hacks like absolute positioning and “visual order ≠ tab order.”
• Avoid keyboard traps
  • Users must not become stuck inside a component when navigating with a keyboard.
• Provide visible focus
  • Keyboard users must be able to see where focus is on the page.
  • Visible focus helps prevent accidental actions and supports users with low vision and some screen-reader users who still visually orient.

Attention, distraction, and timing

• Let users control time limits
  • Users must be able to extend/adjust/disable time limits to reduce stress and prevent loss of progress.
• Pause/stop/hide motion and distractions
  • Provide controls to pause/stop/hide:
    • blinking
    • scrolling
    • auto-updating content
• Avoid flashing content
  • Keep flashing content under the threshold to reduce risk of migraines, dizziness, nausea, and seizures.

Forms and input usability (memory/orientation support)

• Every input needs a clear, visible label
  • Don’t rely on placeholder text only.
  • Reason given: users with attention/memory challenges may forget what the placeholder refers to.
• Checkboxes and radio buttons must be real form controls
  • They must be actual input elements (not styled divs).
  • Ensure:
    • usable by mouse and keyboard
    • readable by screen readers
    • accessible name/label is correctly connected (via ID/for associations)
    • the question/instructions are properly presented so users know what they’re selecting.

Video accessibility (hearing impairments)

• For pre-recorded videos
  • Provide captions (VTT format)
  • Captions must be:
    • visible and optionally user-selectable
    • include both speech and important sounds
    • have the correct language marked
  • Add caption tracks for the relevant language(s).
  • The talk highlights testing by ensuring the caption text aligns with timestamps.
• For live videos
  • Captions must be:
    • real time
    • accurate enough to follow the event
    • include speech and important sounds
  • Examples mentioned:
    • real-time captioning services (e.g., broadcast-style)
    • CART/real-time translation captions (including benefits for both remote and in-person contexts).

Ongoing workflow and team practices

• Use scanners/tools during development
  • Run automated checks (speaker mentions a tool named “PI” and “pa lci/polyci” style as used by them).
  • Add scanners to CI/pipeline where possible.
• Learn and test with a screen reader
  • Don’t assume users are experts.
  • Test your own site with a screen reader to catch issues.
• Take accessible courses
  • The speaker recommends short courses as practical investments.
• Keep design simple
  • The speaker argues that accessibility doesn’t have to be “expensive” or “no design.”
  • A simple accessible design is better than a visually designed but inaccessible one.
• Don’t treat accessibility as optional
  • Accessibility must be prioritized; otherwise you actively discriminate by excluding users.

---

Speakers / sources featured (identified at end)

• Elise/Elisa Kristiansen / Elisa Christensen (primary speaker; front-end developer; also references “Elisa Christensen” as her contact name)
• Mat Stan / Mutz (Norwegian gamer; described as also known as “Eblyn/Ebnelin” in World of Warcraft; the story discussed to illustrate the importance of accessible games and community)
• Gabrielle Zevin (author referenced for a quoted passage from Tomorrow, and Tomorrow, and Tomorrow)
• NDC Copenhagen 2026 (event context mentioned in the talk title)