The Accessibility Standard Designers Can’t Ignore in 2026: What the EAA Actually Requires

Two years after a product launch, a design-system audit flagged one of our primary buttons for insufficient color contrast.

The fix itself was almost embarrassingly simple: change a token, update the component, regression-test the affected states, ship. What bothered me was everything that had happened before that fix. The inaccessible color combination had existed in the design library, survived design critique, appeared in approved Figma screens, passed handoff, been implemented faithfully by engineering, and then propagated wherever that component was reused.

The developer had not introduced the accessibility failure. We had designed it.

That experience changed how I think about accessibility reviews. By the time an engineer is measuring contrast against production CSS, checking keyboard focus in a browser, or discovering that an icon button has no meaningful accessible name, the organization is already paying for a decision that could have been caught much earlier.

That distinction matters more in 2026 because the European Accessibility Act is no longer a future deadline. The European Commission says Member States had to incorporate the Act into national law by June 2022, and covered requirements began applying from June 28, 2025. W3C's Web Accessibility Initiative lists the EAA as covering both public- and private-sector activity, extending beyond the web, and using WCAG 2.2 as its WCAG reference point.

So European Accessibility Act UI/UX Design in 2026 is fundamentally a question about what designers put into design files before code exists: contrast, target dimensions, states, navigation behavior, labels, focus treatment, help placement, and alternatives to purely visual communication.

Those are exactly the decisions this guide breaks down. For designers building the broader foundation behind them, the Refonte Learning UI/UX Designer Program already lists “Accessibility in Design” among its competencies alongside design systems, responsive design, prototyping, research, and interface design.

The Compliance Failure That Started in a Design File, Not in Code

Accessibility bugs are often filed like engineering defects: “button contrast fails,” “keyboard focus missing,” “target too small,” “screen reader label incorrect.”

That classification can hide the real origin.

Consider the contrast failure I described. The production button inherited its foreground and background values from the approved design system. Engineering implemented the specified colors correctly. Testing against WCAG later showed that the visual decision itself did not meet the required contrast threshold.

This is why accessible design compliance cannot be reduced to running an automated checker after implementation. W3C's WCAG 2.2 requirements govern user-facing outcomes, but many of the choices that determine those outcomes happen before HTML, CSS, JavaScript, Swift, Kotlin, or any other implementation layer is written.

The designer does not own every part of conformance. Programmatic semantics, DOM order, native control behavior, assistive-technology interoperability, and keyboard implementation all require engineering expertise.

But design owns enough of the upstream decisions that accessibility has to become part of design quality.

My rule now is simple: when an accessibility issue can already be seen or inferred from the approved design specification, discovering it for the first time in code review is a process failure.

A useful design-review checklist starts with:

• Can every important state be distinguished without relying only on color?

• Do text, controls, borders, and state indicators have intentional contrast specifications?

• Is there a designed keyboard-focus treatment?

• Are interactive target areas large enough?

• Does every icon-only action have a documented purpose?

• Do repeated navigation and support patterns remain predictable?

Those questions do not replace accessibility testing. They stop preventable accessibility debt from entering the build.

What the European Accessibility Act Actually Covers

The European Accessibility Act is Directive (EU) 2019/882. The European Commission describes its purpose as improving the EU internal market for accessible products and services by reducing barriers created by differing national accessibility rules.

That matters because many product teams still hear “European accessibility” and mentally translate it into “government websites.”

That is too narrow.

The Commission's current EAA guidance lists covered categories including computers and operating systems, ATMs and ticketing/check-in machines, smartphones, equipment related to digital television, telephony services, access to audiovisual media services, certain passenger-transport services, banking services, e-books, and e-commerce.

The directive defines e-commerce services around services provided at a distance through websites and mobile-device-based services by electronic means, which makes the connection to product-design work direct rather than hypothetical.

W3C's Web Accessibility Initiative consequently categorizes the EAA as not web-only and as having both public- and private-sector scope.

Why "Not Web Only" Matters for Designers

A web-only mental model encourages teams to treat accessibility as something a frontend developer handles through semantic HTML and CSS.

The EAA's broader scope breaks that assumption.

A banking mobile app may have no traditional webpage in the interaction a customer is completing. A self-service ticket machine combines industrial design, touch interaction, information architecture, hardware controls, typography, motion, audio, and software. An e-reader experience can involve reading controls and content behaviors that go well beyond conventional website layouts.

That leads to a more useful question during product definition:

What must a user perceive, understand and operate to complete this task, regardless of interface technology?

For designers, the practical implications include:

• Do not restrict accessibility acceptance criteria to browser-based screens.

• Include mobile-native components, kiosks and other covered user interfaces in accessibility reviews.

• Specify alternatives when an interaction depends primarily on sight, color, fine motor precision, hearing, dragging, or memory.

• Treat authentication, payment and error-recovery flows as accessibility-critical product journeys.

The EAA therefore belongs in product requirements, design-system governance and design QA, not only in a web-development checklist. The law's market scope determines whether a particular product or service is covered, so organizations still need qualified legal advice for scope decisions.

The EAA's Timeline: Why 2026 Is Inside the Active Window

The most consequential date for product teams is June 28, 2025.

That date has already passed.

The European Commission says EU Member States had to incorporate the EAA into national law by June 2022. AccessibleEU, the EU accessibility resource center, states that the Act came into effect on June 28, 2025.

There is a small historical-date nuance worth getting right. Directive (EU) 2019/882 itself is dated April 17, 2019, while W3C WAI's EU policy tracker lists June 27, 2019 as the EAA's enacted date.

This makes the framing of eaa design requirements 2026 different from an article that could have been written in 2023.

Back then, a design leader could reasonably say, “We need to prepare before the 2025 deadline.”

In August 2026, that sentence is obsolete.

The more appropriate questions are now:

• Are our current design-system components accessibility-ready?

• Are new features being reviewed against accessibility criteria before handoff?

• Are legacy journeys being remediated systematically?

• Can we demonstrate why specific component decisions were made?

• Does the design organization understand which WCAG requirements it materially influences?

There are transitional provisions and scope nuances within the EAA, and individual national implementations matter. The fact that some transitional arrangements exist does not turn June 28, 2025 into a general extension for all digital design work.

For the typical UI/UX team shipping covered e-commerce, banking or other consumer digital experiences into the European market, 2026 belongs on the “operate under the requirement” side of the roadmap.

WCAG 2.2 as the EAA's Reference Standard

This is where I would add an important practitioner-level qualification to the sentence “the EAA uses WCAG 2.2.”

W3C WAI's EU policy tracker, updated July 23, 2025, explicitly lists WCAG Version Used: WCAG 2.2 for the European Accessibility Act.

But the EAA should not be described as though Directive 2019/882 simply copied the WCAG 2.2 success criteria into the statute. The European Commission's 2026 ICT standardization rolling plan shows that EN 301 549, the European ICT accessibility standard, is being revised under Commission standardization request M/587 to support the EAA framework.

That distinction matters because wcag 2.2 for designers should be taught as an operational accessibility framework, not as amateur legal interpretation.

For web and interface teams, WCAG gives us something extremely valuable: measurable criteria.

Instead of saying “make buttons accessible,” we can ask whether text meets 4.5:1 contrast where required, whether essential non-text interface information meets 3:1 contrast, whether keyboard focus remains visible, whether focused elements become obscured, whether pointer targets satisfy WCAG 2.2's minimum target-size rule, and whether repeated help mechanisms remain consistently ordered.

That converts accessibility from taste into acceptance criteria.

The design-relevant WCAG requirements discussed in this article include:

• 1.4.3 Contrast (Minimum), Level AA

• 1.4.11 Non-text Contrast, Level AA

• 2.4.7 Focus Visible, Level AA

• 2.4.11 Focus Not Obscured (Minimum), Level AA

• 2.4.13 Focus Appearance, Level AAA

• 2.5.8 Target Size (Minimum), Level AA

• 3.2.3 Consistent Navigation, Level AA

• 3.2.6 Consistent Help, Level A

• 1.1.1 Non-text Content, Level A

• 2.5.3 Label in Name, Level A

The strongest UI/UX organizations turn criteria like these into component rules rather than expecting every designer to remember specification numbers on every project.

Color Contrast: The Requirement Designers Get Wrong Most Often

Contrast is where accessibility failures often become visible first because color is so heavily controlled by the design discipline.

WCAG 2.2 Success Criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large-scale text, with specified exceptions. W3C defines the large-text threshold around 18pt regular or 14pt bold and cautions that the contrast ratios are thresholds: 4.499:1 does not round up to a passing 4.5:1.

Those are the core wcag color contrast requirements a UI designer needs to know.

The common design-system mistake is testing individual palette colors instead of semantic pairings.

A blue token does not “pass accessibility.” It passes or fails against a specific adjacent color in a specific use case.

I want contrast documentation to look like this:

• text/default on surface/default: approved for body text.

• text/subtle on surface/default: approved or prohibited by size/use.

• button/primary-label on button/primary-bg: approved.

• border/input-default against adjacent surface: tested for its visual role.

• focus/ring against the colors it may touch: tested across realistic contexts.

That is far more useful than a palette page showing twenty attractive swatches with no usage constraints.

The other recurring failure is state coverage. Teams test the default button but not disabled, hover, selected, error, pressed, visited or focus states.

W3C's non-text contrast rule also applies to visual information needed to identify user-interface components and their states.

That means a pale form boundary can matter. So can the visual treatment distinguishing selected from unselected controls.

Designers should also remember that WCAG 1.4.1 says color must not be the only visual mechanism used to convey information or distinguish an actionable state.

An error field that changes its border from gray to red but provides no icon, text or other indication is therefore a poor accessibility pattern even when the red itself has excellent contrast.

The design-review standard I use is stricter than “the contrast plugin shows green.” I ask whether a user could still understand the component when hue perception, contrast sensitivity, zoom, brightness conditions, or visual attention are not what the design team assumed.

Focus Indicators: Designing for Keyboard and Switch Navigation

Most design systems I audit contain hover states.

Far fewer contain thoughtfully designed focus states.

That imbalance tells you whose interaction the component library was implicitly designed around.

WCAG 2.2 Success Criterion 2.4.7, Focus Visible, is Level AA. W3C explains that keyboard users need a visible way to determine which component currently has keyboard focus and that an author must provide at least one mode of operation in which focus is visible.

The designer's deliverable should therefore not contain only:

Default → Hover → Pressed → Disabled

It should include:

Default → Hover → Focus → Pressed → Selected → Error → Disabled

And combined states matter.

What happens when a selected checkbox receives focus? What does focus look like on an error field? Can the focus treatment still be seen on dark and light surfaces?

That is focus indicators design as a system problem rather than a one-off blue outline.

What "Visible" Actually Means Under WCAG 2.2

There is an important WCAG-level distinction here.

Focus Visible, SC 2.4.7, is Level AA. Focus Appearance, SC 2.4.13, is Level AAA. W3C explicitly points to Focus Appearance as stronger guidance around the size, shape and contrast of the focus indicator.

SC 2.4.13 specifies an indicator area at least equivalent to a 2 CSS-pixel-thick perimeter of the unfocused component and requires at least 3:1 contrast between the corresponding focused and unfocused pixels, subject to its exceptions.

That does not mean every EAA implementation can be summarized as “a two-pixel focus ring is legally mandatory.”

It means a mature design team can use the AAA Focus Appearance criterion as a concrete robustness target while understanding which WCAG conformance level each criterion occupies.

WCAG 2.2 also added the Level AA Focus Not Obbd268scured (Minimum) requirement. W3C specifically identifies sticky headers, sticky footers and non-modal dialogs as common content that can hide a focused control.

So the design question is not merely “Do we have a focus ring?”

It is “Can the keyboard user track focus through the interface we actually designed?”

Touch Target Size: A Requirement Mobile Designers Miss

Touch-target guidance is another area where product teams repeat a simplified number without checking what WCAG actually says.

WCAG 2.2 introduced Success Criterion 2.5.8 Target Size (Minimum) at Level AA. Its default requirement is at least 24 by 24 CSS pixels, subject to defined exceptions including spacing, an equivalent target, inline targets, user-agent-controlled targets, and essential presentations.

This distinction matters because “WCAG requires every button to be 44 by 44” is not an accurate description of WCAG 2.2 AA.

At the same time, designing everything to the smallest technically permissible target is rarely good mobile UX.

From a design-system perspective, touch target size accessibility is better handled by separating the visual icon from the interactive hit area.

A close icon can look 16 × 16 while living inside a comfortably larger button target. A checkbox glyph can remain visually compact while the label and surrounding area participate in the clickable control.

The Minimum Sizes WCAG 2.2 Actually Specifies

W3C's explanation of SC 2.5.8 goes beyond a simplistic box measurement.

A target at least 24 × 24 CSS pixels passes the default size requirement. An undersized target may still qualify through the spacing exception when the required 24 CSS-pixel conceptual circles around undersized adjacent targets do not intersect.

Designers should still be cautious about designing around exceptions.

A practical component policy can be:

• 24 × 24 CSS px: WCAG 2.2 AA baseline to understand.

• 44 × 44 CSS px or larger: strong design-system target for important controls where the interface allows it, corresponding to WCAG's enhanced AAA criterion.

• Do not make users rely on tiny adjacent icons merely because a spacing exception might technically apply.

• Test dense toolbars, pagination, chips, close buttons, calendar controls and table actions explicitly.

The W3C notes that the minimum-target criterion benefits not only touchscreen users but also people using a mouse or pen who have tremor or reduced fine-motor precision.

That is exactly why this belongs in the component specification.

You cannot fix a system full of 16-pixel interaction boxes elegantly at the end of development without changing layouts.

Non-Visual Alternatives for Interactive Elements

A designer does not write ARIA attributes in Figma.

A designer absolutely can create an interaction whose meaning is impossible for an engineer to represent correctly without guessing.

The classic example is a row of unlabeled icons.

WCAG 2.2 SC 1.1.1 requires non-text content to have an appropriate text alternative, and where non-text content is a control or accepts user input, it needs a name describing its purpose.

WCAG 2.2's Label in Name criterion adds another important interaction-design detail. For a control with a visible text label, the programmatic name must contain that visible text; W3C explains that this is particularly important for speech-input users who try to activate controls by saying the label they can see.

Imagine a visible button saying “Book ticket” while its programmatic name says “Continue.”

A sighted speech-control user naturally says “Click Book ticket.” The software is looking for “Continue.”

That mismatch was created conceptually before anyone argued about ARIA.

For handoff, I recommend annotating at least:

• control purpose;

• intended accessible name for icon-only controls;

• visible label where applicable;

• relevant state: expanded/collapsed, selected/unselected, checked/unchecked;

• error messaging;

• whether descriptive content should be associated with a field;

• expected keyboard interaction when a custom component is unavoidable.

These annotations do not tell an engineer exactly which implementation mechanism to use.

They tell engineering what the interaction is supposed to mean.

That is the designer's job.

Consistent Navigation and Help Placement Requirements

Accessibility is not only about individual controls.

Predictability across screens matters too.

WCAG 2.2 SC 3.2.3, Consistent Navigation, is Level AA. It requires navigation mechanisms repeated across multiple pages in a set of pages to occur in the same relative order unless the user initiates a change.

WCAG 2.2 also introduced Consistent Help, SC 3.2.6, at Level A. When specified help mechanisms are repeated across pages, they must occur in the same relative order unless a user-initiated change applies.

W3C is explicit that Consistent Help does not force every website to provide help. The rule applies when qualifying mechanisms, such as human contact details, contact mechanisms, self-help options or automated contact mechanisms, are repeated across a set of pages.

This is a design-system issue because headers, footers, navigation, account menus, support buttons and chat launchers often live in shared templates.

A designer who creates four checkout layouts with support in four different places has introduced unpredictability into the experience.

I would therefore treat repeated help and navigation like components with positional contracts.

The pattern library should specify not just what these elements look like, but where they appear relative to the rest of repeated page structure.

That is accessibility through information architecture.

Why Catching This in Code Review Is Already Too Late

Developers should test accessibility.

QA should test accessibility.

Neither fact justifies making engineering the first stage where obvious accessibility decisions are evaluated.

Once an inaccessible component reaches implementation, remediation can involve design-system changes, new acceptance criteria, updated variants, product approval, developer rework, regression testing and communication to every team consuming that component.

The European Commission's guidance on web accessibility makes the same underlying point from the implementation side: tools or overlays that do not make the underlying website meet detailed accessibility criteria are not an appropriate substitute, and accessibility issues should be fixed at their source.

Design is one of those sources.

This matters even more as generative workflows accelerate production. Refonte Learning's recent article on AI design-to-code tools compared examines tools that increasingly narrow the gap between a design decision and running software; that makes upstream judgment more valuable, not less.

A generator can reproduce an inaccessible component faster than a human developer.

Speed does not turn the component into a good decision.

Building Accessibility Checks Into the Design Review Itself

I prefer a two-gate model.

The first gate happens when a reusable component enters or changes inside the design system. The second happens when that component is used in a real product flow.

At the component gate, reviewers check:

• contrast combinations;

• default, hover, focus, pressed, selected, disabled and error states;

• target dimensions;

• visible labels and icon purposes;

• responsive behavior;

• how the component behaves with long content;

• keyboard interaction expectations.

At the flow gate, reviewers check:

• navigation consistency;

• focus sequence assumptions;

• sticky elements and overlays that could obscure focus;

• error recovery;

• support placement;

• whether color or position is carrying meaning alone;

• whether instructions depend on sensory language such as “click the green icon on the right.”

W3C's WCAG 2.2 criteria on focus, target size, contrast, consistent navigation and consistent help provide measurable anchors for exactly these reviews.

The result is not “design certifies WCAG compliance.”

The result is that design stops knowingly sending avoidable failures downstream.

What Enforcement Actually Looks Like (and What's Still Unclear)

This is the section where accessibility content often becomes less trustworthy than the legislation.

You will find dramatic EAA fine figures repeated across vendor blogs, frequently without a clean chain back to national law.

I would not build the business case that way.

Directive 2019/882's Article 30 requires Member States to establish penalties for infringements of their national implementing provisions. EUR-Lex's published text confirms the Directive contains separate enforcement and penalty provisions, while the European Commission says it monitors implementation and transposition and has established an expert group involving national administrations and market-surveillance authorities.

AccessibleEU also warned before application that failure to comply could lead to penalties, while emphasizing the Act's June 28, 2025 effective date.

The confidence level on the deadline and the existence of enforcement mechanisms is therefore high.

The confidence level on broad claims about a settled body of 2026 EAA case law is much lower.

The EAA authorizes penalties, though widely-reported enforcement case data specific to 2026 was not available at the time of writing. My research for this article did not identify sufficiently authoritative, dated evidence of a concrete 2026 EAA enforcement case that would justify turning one into a headline anecdote.

That is not a reason to ignore the Act.

It is a reason to use the facts that are already stronger: the application date has passed, covered products and services are inside an active legal framework, national authorities have compliance responsibilities, and WCAG provides concrete interface requirements teams can work against now.

For legal determinations about whether a particular organization, service, exemption, transition provision or national penalty applies, accessibility teams should work with qualified counsel in the relevant jurisdiction.

Designers still do not need to wait for a court case before fixing a 3.2:1 body-text button.

Building an Accessibility Checklist Into Your Design System

A mature accessibility practice does not ask every designer to rediscover WCAG from scratch.

It converts repeatable accessibility requirements into design-system constraints.

That is where accessibility in design skills become scalable.

Start with tokens.

Do not document gray-500 as “accessible.” Document which semantic foreground/background combinations are approved for which uses.

Then move to components.

Every interactive component should have a complete state matrix. Every icon-only control should have an accessible-purpose annotation convention. Every component with a compact visual footprint should specify the actual interactive area.

For teams comparing tool workflows, Figma vs. Sketch vs. Adobe XD compared covers the software landscape separately; the accessibility layer discussed here is deliberately tool-agnostic because WCAG requirements do not disappear when a team changes its design application.

The component library should also tell designers what not to do.

That means documenting prohibited examples such as low-contrast tertiary text, error states differentiated only through red, icon buttons below your approved target policy, focus treatments that disappear against common surfaces, and custom navigation variants that reorder persistent elements unpredictably.

Auditing an Existing Design File for These Issues

When I inherit a mature product, I do not begin by auditing hundreds of screens independently.

I start with multiplication points.

That normally means the color variables/tokens, typography styles, core form controls, buttons, icon buttons, navigation, modals, menus, tables, alerts, toasts, authentication screens and checkout/payment flows.

A practical audit sequence is:

• Inventory: identify reusable components and semantic color tokens.

• Contrast pass: test common text/background and component-state combinations against WCAG 1.4.3 and 1.4.11.

• State pass: verify focus, hover, error, selected and disabled variants exist where appropriate.

• Target pass: measure interactive areas against the 24 × 24 CSS-pixel WCAG 2.2 minimum concept and your organization's larger preferred target.

• Meaning pass: identify icon-only controls and interactions where accessible purpose is undocumented.

• Consistency pass: compare repeated navigation and support placement across templates.

• Overlay pass: review sticky bars, cookie banners, drawers and dialogs for focus-obscuring risks.

• Flow pass: audit authentication, payment, destructive actions, errors and task recovery as complete journeys.

Then fix the highest-level source you can.

If twenty-seven screens fail because one button component is wrong, repair the component before patching twenty-seven frames.

If six components fail because text/subtle is incorrectly permitted on surface-muted, fix the token usage rule.

This is where accessibility and good design-system architecture reinforce one another.

The objective is not to make the audit spreadsheet prettier.

It is to make the next inaccessible screen harder to create.

UI/UX Designer Salaries in 2026

Accessibility competence is becoming more relevant inside a field that already commands substantial compensation in the United States, but salary data needs to be presented carefully.

As of August 9, 2026, Indeed reports an average U.S. base salary of $107,482 per year for UX/UI Designers, with a reported low of $65,463 and high of $176,471. Indeed says that figure is based on 783 salaries from job postings over the preceding 36 months.

That is useful ui ux designer salary 2026 context, but it should be treated as one market data point rather than a universal salary benchmark. Compensation varies materially by experience, location, employer, specialization and job scope.

Indeed's live page also illustrates the geographic variation: its August 2026 data lists San Francisco above its national figure, followed by markets including New York and Denver at different levels.

I would therefore not tell an early-career designer, “Learn accessibility and you will earn $107,482.”

I would tell them something more defensible: accessibility literacy increases the range of product risks you can identify and the quality of design decisions you can make, particularly on teams operating across regulated markets.

That makes it a professional capability, not a salary hack.

Accessibility also cuts across role boundaries. A UI designer may own contrast, component states and visual hierarchy; a UX designer may own flows, navigation consistency, error recovery and research; product designers often touch both. Refonte Learning's UI Designer vs. UX Designer guide covers those role boundaries separately.

The more senior you become, the less valuable it is to say, “Accessibility belongs to engineering.”

Senior designers are expected to understand the consequences of the systems they approve.

Building This Skill Set: The Refonte Learning UI/UX Designer Program

The strongest reason to learn accessibility is not that WCAG gives you another checklist.

It is that accessibility forces you to become more precise about interaction design.

You start asking better questions: What is the actual target? What happens on focus? What does this control mean without the icon? Is the error identifiable without red? Is the interaction possible without dragging? Does the navigation behave predictably? Can another designer accidentally create a failure using the system I built?

Those are senior-product-design questions.

For beginners building that foundation, the Refonte Learning UI/UX Designer Program is a relevant starting point because its live curriculum already includes “Accessibility in Design” among the competencies students develop. It also lists UI design, UX research, prototyping and wireframing, information architecture, usability testing, design systems, typography and color theory, responsive design, and Figma, Sketch and Adobe XD.

These details come directly from the current Refonte Learning program page. The page describes the program as three months at 10–12 hours per week, states that no prior design experience is required while listing pursuit of a bachelor's degree or higher as an admission prerequisite, and identifies David A. Thompson as the program's UI/UX mentor and Senior Product Designer.

The curriculum is organized around Introduction to UI/UX Design Fundamentals, Designing User-Centered Interfaces, and Mastering Wireframing and Prototyping Tools, with Figma and Adobe XD specifically named in the prototyping module.

Current pricing is $300 as a one-time payment, with an installment option of $204 plus $98. The wider program listing displays the UI/UX Designer program at $300 against a $387 reference price and describes the offer as 30% off.

The page lists career outcomes including UI/UX Designer, Product Designer, Interaction Designer and UX Researcher.

There is one boundary I would keep explicit.

Refonte Learning currently lists “Accessibility in Design,” but the public program page does not specifically say that it teaches WCAG 2.2, the European Accessibility Act, or EAA compliance in depth.

That should not be inflated into a claim the curriculum does not make.

Instead, treat the program as the existing foundation: user-centered design, design systems, prototyping, responsive interfaces and accessibility awareness. Then apply the more specific WCAG 2.2 requirements covered in this article to the work you create.

For someone beginning now, I would turn those requirements into portfolio evidence.

Take a button component and document compliant text and state contrast. Design its keyboard-focus treatment. Define a meaningful interactive area. Annotate an icon-only variation with its intended accessible purpose. Build a form showing labels, instructions, focus, error behavior and recovery.

Then show the inaccessible version beside the corrected system.

That tells a hiring manager far more than writing “WCAG” in a skills list.

The practical lesson of european accessibility act ui ux design is that designers cannot hand accessibility downstream and call their job complete. The EAA has been in its application period since June 28, 2025; W3C WAI lists WCAG 2.2 as the EAA's WCAG reference; and the criteria that affect everyday interface work reach directly into contrast, focus, targets, alternatives, navigation and help patterns.

The contrast failure that reaches production may eventually be repaired in CSS.

But the cheapest, cleanest and most professional version of that fix is still the one you make before handoff, inside the design system, while it is still just a design decision.