You've reached the last lesson of the course. You've come a long way: from not knowing what accessibility was to building, verifying, and maintaining an accessible, dynamic, app-like, and multilingual platform—Cursalia. Before we close, it's worth lifting our eyes from the code and looking at the horizon: where is all of this heading? The standard is changing (WCAG 3.0 is on the horizon), the law is tightening (the European Accessibility Act is already in force), artificial intelligence enters the scene with its promises and its risks, and accessibility spills beyond the web toward mobile, voice, and extended reality. This lesson gives you a map of that future so it doesn't catch you off guard, with one important warning: the regulatory and technical landscape moves fast; what's described here is a snapshot of 2026 and you should always verify it against up-to-date sources and specialists. And at the end, we'll close the whole journey together.

1. WCAG 3.0 (Silver): a new model, still in development
2. The evolution of ARIA
3. The legal push as a market driver
4. Artificial intelligence: the double-edged sword
5. Accessibility beyond the web
6. Personalization and user preferences
7. The cultural shift: "shift-left"
8. A warning about shifting ground
9. Common mistakes and tips
10. Exercises
11. Course wrap-up

Throughout the course you've worked with WCAG 2.2, the current standard, with its structure of pass/fail criteria (A / AA / AAA) that you saw as requirements in Module 3. On the horizon is WCAG 3.0, whose code name is "Silver". It's a deep redesign, not a simple update to the list of criteria. The most important thing you need to know:

WCAG 3.0 is in development and does NOT replace WCAG 2.2. It's a W3C working draft; its publication as a recommended standard is years away. Today, and for a good while, your reference is still WCAG 2.2. WCAG 3.0 is where we're looking, not what we apply yet.

What it proposes to change relative to 2.x:

The idea of graded scoring is to move past the "all or nothing" approach. With 2.2, a single unmet criterion knocks out the AA conformance of an entire page, even if the other 99% is impeccable. The 3.0 model seeks to better reflect the real experience: how accessible something is, not just whether it passes or fails a threshold. It's a shift in philosophy that fits what you learned in Module 6 about prioritizing by real user impact, not by the number of errors.

ARIA, which you mastered in Modules 4 and 5, is also evolving. It's a living specification that expands to cover new patterns and refine existing ones. Two fronts to follow:

• New roles and attributes: they're added as interface patterns appear that native HTML semantics don't cover. The ARIA Authoring Practices Guide (APG), your "contract of behavior" from Module 5, is updated in parallel.
• The golden rule doesn't change: "no ARIA is better than bad ARIA". The more capable native HTML becomes (for example, elements like <dialog> that you already used, or emerging native popovers and controls), the less manual ARIA you need. The underlying trend is for the web platform to absorb patterns that once required hand-written ARIA, reducing the surface for error.

The practical lesson: always prioritize the native HTML element; resort to ARIA only when no native alternative exists, and keep an eye out for whether a pattern you code by hand today becomes natively supported.

Accessibility has stopped being "an optional best practice" and has become a legal obligation in more and more territories, and that is probably the biggest market driver of change. The most relevant recent milestone in Europe:

The European Accessibility Act (EAA)—Directive (EU) 2019/882—has been applicable since June 2025. It requires many digital products and services (e-commerce, banking, transport, e-books, and online services in general) to meet accessibility requirements in order to be sold in the EU.

Practical consequences you're already noticing:

• Accessibility goes from "we'll do it if there's time" to a requirement to operate in a market. Recall from Module 6 that a buyer (a university that contracts Cursalia) demands an ACR/VPAT: that becomes widespread and legally enforceable.
• Demand grows for profiles with accessibility knowledge—exactly what you've acquired in this course.
• Alongside the EAA, other regulations coexist (the European standard EN 301 549, Section 508 in the US, national laws…). The specific detail varies by jurisdiction and changes: always verify the one that applies to you.

The message: accessibility today is also a matter of compliance and business, not just ethics. Both push in the same direction.

AI is the most talked-about and most misunderstood trend in accessibility. It has enormous potential and equally real risks. The key is to understand where it helps and where it deceives.

The golden rule with AI in accessibility is the same one you learned in Module 6 about automated tools: they're a starting point, never the verdict. An AI-generated alt that says "a person sitting in front of a computer" can be correct and useless at the same time, if the purpose of that image in Cursalia was to show "a student completing the course's final quiz". AI doesn't know the intent; you do. And above all:

AI does not replace testing with real users (Module 6, 06-03). No tool, however smart, will tell you what Marta told you when she didn't hear her enrollment message. Use AI to speed up repetitive work and always review its output with human judgment and with users.

Overlays deserve a separate warning: the widgets that promise "accessibility compliance with one line of code" are widely rejected by the community of people with disabilities, because they often interfere with the assistive technologies the user already has configured. There are no shortcuts: accessibility is built into the product, not pasted on top.

Everything you've learned—semantics, focus, text alternatives, keyboard—transcends the browser. The future is multi-platform:

• Mobile and native apps: iOS and Android have their own accessibility APIs (VoiceOver, TalkBack) and their own guidelines. The POUR principles from Module 3 are the same; the tools change.
• Voice interfaces (smart-speaker-type assistants): with no screen, accessibility is the whole interaction. They pose new challenges for deaf people (Diego) or those with speech difficulties.
• XR / AR / VR (extended reality): immersive environments where almost the entire vocabulary of accessibility is missing. How does Marta navigate a 3D space? How does Lucía receive spatial subtitles? It's an open frontier, with standards still in their infancy.

The pattern repeats: the principles (perceivable, operable, understandable, robust) remain; the techniques are reinvented for each medium. Whoever understands the principles—you, now—adapts to any platform.

A solid and already very usable trend today: respecting the preferences the user declares in their system, which the browser exposes as CSS media queries. Instead of imposing a single experience, you adapt it to each person:

prefers-reduced-motion is especially important and you should already be using it: motion can cause dizziness or disorientation (related to WCAG 2.3.3 and 2.2.2 from Module 3), and it bothers people with ADHD like Hugo. The trend is toward more signals of this kind (typography preferences, data reduction, transparency), moving accessibility from a one-size-fits-all approach to a personalized experience that respects what each user has already configured.

Perhaps the most important trend isn't technical but about process. For years, accessibility was a final phase: the product was built and, at the end, someone "made it accessible" (or tried to). That model is dying. The "shift-left" movement means moving accessibility to the left in the development cycle: having it present from the design stage, not as a final patch.

This connects directly to what you saw in Module 6: accessibility in the Definition of Done, the linter in CI, automated axe tests, the manual checklist on each component. The underlying idea:

Accessibility is the responsibility of the whole team—design, development, content, QA, product—and of the whole cycle, not of one person or one phase. It's cheaper, more effective, and more humane when it's thought about from the start.

Designing accessibly from the beginning costs a fraction of what it costs to remediate at the end. And it produces better products for everyone, not just for those with a disability.

An honest heads-up to close the technical part: everything in this lesson evolves fast. WCAG 3.0 will advance and its model may change; ARIA will add roles; legislation will broaden and vary by country; AI will improve (and bring new risks); platforms will emerge that we can't imagine today. The specific dates and details given here are a snapshot of 2026.

That's why, rather than memorizing the current state, take away the habit of verifying: consult primary, up-to-date sources (the W3C/WAI, official documentation), follow the accessibility community, and, for important legal or conformance decisions, rely on specialized professionals. The principles you've learned are stable; the details are not. Stay up to date.

• Believing WCAG 3.0 already replaces 2.2. It doesn't: 2.2 is the current reference; 3.0 is in development. Applying 3.0 today as if it were mandatory is a mistake.
• Blindly trusting AI. Automatic alt and subtitles are a draft that must be reviewed. AI doesn't know the purpose and doesn't replace real users.
• Falling for overlays. There's no "one line of code" that makes a site accessible; they usually make the experience worse.
• Thinking accessibility is only for the web. Mobile, voice, and XR apply the same principles with different techniques.
• Ignoring prefers-reduced-motion and prefers-contrast. They're available today and respect what the user already asked for. Use them.
• Treating accessibility as a final phase. "Shift-left" moves it to design; remediating at the end is more expensive and worse.
• Tip: don't memorize dates or versions; internalize the principles and adopt the habit of verifying against up-to-date sources. The standard changes; the why doesn't.

Exercise 1. A product manager tells you: "I've read that WCAG 3.0 scores from 0 to 100 instead of pass/fail, so from now on we'll audit Cursalia with WCAG 3.0". Point out what's true and what's mistaken in their statement, and what you'd recommend.

Exercise 2. The team wants to subtitle Cursalia's 200 videos with an AI tool to meet Diego's needs and the law. Explain the benefit and the risk, and describe a responsible workflow that uses AI without giving up quality.

Exercise 3. Add to Cursalia's stylesheet respect for two system preferences: reducing the motion of the home carousel and increasing contrast if the user has it configured. Write the CSS and explain which person from the course each rule helps.

Solution 1. True: WCAG 3.0 proposes a graded scoring model instead of the binary pass/fail of 2.2. Mistaken: WCAG 3.0 is in development and is not yet a recommended standard; it doesn't replace WCAG 2.2, which remains the current reference and the one that's legally enforceable. Recommendation: keep auditing with WCAG 2.2 (level AA) as the conformance baseline, watch the evolution of 3.0 to prepare, but don't adopt it as the official criterion until it's published and required by the applicable regulations. Verify the status in the W3C/WAI sources.

Solution 2. Benefit: AI subtitles 200 videos in a fraction of the time and cost of doing it by hand, which makes the goal feasible. Risk: automatic subtitles fail on proper names, technical terminology, punctuation, and with accents or noise; published without review, they give Diego a poor experience and might not truly comply with the law (WCAG 1.2.2, Module 5). Responsible workflow: (1) generate the draft with AI; (2) mandatory human review of each video, correcting terms, names, and punctuation; (3) validate the result, ideally with the target person or with someone who uses subtitles; (4) maintain the per-language subtitles (07-03). AI speeds things up; human review guarantees quality.

Solution 3.

The first rule respects prefers-reduced-motion and stops the carousel's animation: it helps Hugo (ADHD/dyslexia), whom motion distracts, and anyone with vestibular sensitivity. The second respects prefers-contrast and reinforces contrast and borders: it helps Sofía (low vision). Both preferences are declared by the user in their system; we only honor them.

And here the journey ends. It's worth looking back and seeing how far you've come.

You started out not knowing what web accessibility was (Module 1) and came to understand that it's not an extra, but a right and a legal obligation. You met the people we work for and the technologies they use (Module 2). You turned the POUR principles into concrete requirements with WCAG (Module 3). You built with semantic HTML, forms, ARIA, and contrast (Module 4); you brought widgets, keyboard, and multimedia to life with JavaScript (Module 5); you learned to verify with manual testing, automated tools, real users, and reports (Module 6); and in this final module you tamed dynamic content and live regions, SPAs, multilingualism, and this glimpse of the future. You raised, piece by piece, an accessible Cursalia: its catalog, its player, its enrollment, its quizzes, its student dashboard, in three languages.

But Cursalia was never the goal. The goal was always people:

• Marta, who now hears the result of her enrollment, navigates the dashboard as a SPA, and hears each language in its correct voice.
• Lucía, who moves through the entire platform with the keyboard without getting trapped or losing the focus.
• Sofía, who zooms to 300% without anything breaking or overlapping.
• Diego, who follows every video with subtitles in his language.
• Hugo, who finds a clear interface, with no motion to distract him, that he can follow at his own pace.

They are the reason behind everything you've learned. Every alt, every aria-live, every well-managed focus, every correct lang is the difference between whether or not they can use what you build.

Remember the two ideas that run through the entire course: accessibility is not a final phase, but a way of working from the very first sketch; and tools help, but nothing replaces testing with real people. If you take that away, you take away the essentials.

The web is built for everyone, or it isn't finished. You now have the knowledge to build it well. The standard will keep changing and there will always be something new to learn—stay curious, verify against up-to-date sources, and keep practicing—but the commitment is the same from the very first lesson to this last one. Thank you for making it to the end. Now go and make it accessible.