标签：#a11y

Two buttons in a confirmation dialog look simple: Cancel and Confirm. Keyboard behavior makes the component a small state machine. A recent MonkeyCode change gives us a concrete example. Issue #862 and PR #863 add these shortcuts to the slash-command confirmation: ArrowLeft -> focus Cancel ArrowRight -> focus Confirm The reviewed implementation at commit c58bcd4 moves focus through button refs. That is a useful extra interaction. It is not a replacement for the dialog's accessibility foundation. Keep the baseline first For an alert-style confirmation, users still need: an accessible name and description; focus moved inside when the dialog opens; Tab and Shift+Tab constrained to dialog controls; Escape to dismiss when cancellation is allowed; visible focus; focus returned to the trigger after close; actual buttons whose labels explain the actions. The WAI-ARIA Authoring Practices Alert Dialog Pattern describes the modal semantics and keyboard foundation. Left/right mapping is a product shortcut, not a required AlertDialog convention. That means we must not steal keys from the established behavior around it. Isolate the extra mapping The companion keyboard.mjs starts with a pure function: export function arrowAction ( key ) { if ( key === " ArrowLeft " ) return " cancel " ; if ( key === " ArrowRight " ) return " confirm " ; return null ; } The event handler ignores unrelated and modified keys: export function handleDialogArrow ( event , controls ) { const action = arrowAction ( event . key ); if ( ! action || event . altKey || event . ctrlKey || event . metaKey ) return false ; event . preventDefault (); controls [ action ]. focus (); return true ; } Notice what is absent: no handler for Tab , Shift+Tab , Escape , or Enter . The native <dialog> and buttons in the minimal demo retain their normal jobs. In a React component, use a well-tested modal/dialog primitive for focus containment and dismissal, then add this narrow handler to its content. A complete minimal dialo

Playing the game of writing technical post was funny two years ago. Now, I am a mod and it is...

I'm Safdar Ali , a frontend engineer in Bengaluru. Last quarter I audited a client dashboard that looked polished — clean Tailwind, smooth transitions, Lighthouse performance in the 90s — and failed basic keyboard navigation in under two minutes. Tab order jumped randomly, modals trapped nothing, and icon-only buttons had no labels. WCAG 2.2 is not a legal checkbox for enterprise contracts alone. It is how you ship React UI that works for everyone: screen reader users, keyboard-only users, people on slow 4G with zoom enabled, and your future self debugging at 11pm. This guide covers the wcag 2.2 react patterns I run before every merge. Why WCAG 2.2 matters for React in 2026 WCAG 2.2 added criteria that directly affect React apps: focus not obscured, dragging movements, target size minimums, and consistent help. React's component model makes accessibility both easier and easier to break — you can encapsulate good patterns in a shared Dialog component, but you can also copy-paste a div-with-onClick button across forty files. The legal landscape in India is catching up. Government portals and fintech products increasingly require accessibility audits before launch. Even when nobody asks, inclusive UI reduces support tickets — unclear error messages and broken focus management generate more "the form is broken" emails than actual backend failures. React does not ship accessible components by default. A is focusable; a is not, unless you wire it. Your job is to make the accessible path the default path in your design system. Focus traps — modals that actually work A focus trap keeps keyboard focus inside a modal until the user dismisses it. Without one, Tab sends focus to elements behind the overlay — confusing for sighted keyboard users and disorienting for screen reader users who hear content from two layers at once. Continue Reading...

In 2024, Apple shipped something genuinely great: AirPods Pro can run a clinical-style hearing test and then act as hearing assistance, tuned to your ears. People love it. There's just one catch — it needs an iPhone to set up, recent AirPods to run, and if you're on Android you get nothing. Meanwhile, the average pair of prescription hearing aids costs about $4,700 , and surveys show a $1,500 device is simply out of reach for more than half the people who need one. There are a billion-plus Android phones out there, most of them sitting next to a pair of ordinary earbuds that already contain everything you physically need: a microphone, a DAC, and speakers. The gap seemed absurd. So I've spent the past weeks building OpenHearing — a free, GPLv3 Android app that does the whole pipeline: Hearing check — a pure-tone test using the modified Hughson–Westlake staircase (the same adaptive up-down procedure audiologists use), per ear, per frequency. Or skip it and type in the numbers from a real audiogram. Sound profile — the results are fitted into a per-ear gain curve (half-gain rule for v1; NAL-NL2 is a pluggable strategy for later). Real-time assist — mic in, per-ear DSP, earbuds out. Quiet speech gets louder. Works with whatever earbuds you already own. No root, no special hardware. It is very deliberately not a medical device — no diagnosis, no treatment claims, big disclaimer before anything plays a tone. Think of it as the open, inspectable "gateway" tier below real hearing care. This post is about the three engineering decisions that turned out to matter most. 1. The safety-critical DSP is pure Kotlin — and that's the whole point An app that amplifies sound directly into human ears has exactly one unforgivable failure mode: being loud when it shouldn't be. So the entire signal chain is plain Kotlin with zero Android dependencies, hidden behind a tiny I/O interface. AudioRecord / AudioTrack is a dumb shell; everything that can hurt someone is JVM-testable: input → EQ

My father is a stroke patient. Watching him try to speak clearly again — with patience, repetition, and no small amount of courage — is what pushed me to build Voice Revive. It’s a free web app for stroke survivors and people with aphasia: pick a category, hear a word, say it back, get forgiving feedback. No accounts, no scores, no pressure. I vibecoded most of it with AI tools, but the reason behind it is deeply personal. If it helps even one person feel a little more confident speaking again, it was worth it. Let’s work together: Voice Revive is a personal project, and I’m open to: Collaboration — features, accessibility, reaching more people who need it Sponsorships — to keep the app free and accessible Part-time / freelance web development — I’m comfortable building with: What I work with today: Next.js & TypeScript Node.js (Express) Python (FastAPI) Tailwind CSS What I’ve built with before (freelance): Kotlin & Java for Android Development(previous experience - freelance) ESP32 & C++ for IOT Development Try it: https://voicerevive.online/ Connect with me: https://www.linkedin.com/in/aaron-mercado-163b02369/

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. This article completes the process of creating a main navigation component that is universally accessible, both perceptually and operatively; can operate in a controlled or uncontrolled state; and is operable when displayed in a horizontal, desktop arrangement as well as in a vertical, mobile scenario. Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 1.0.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered across components, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for Vertical Alignment along with previous requirements. Content Links Introduction Acceptance Criteria Data Setup Keeping SubLists Open Allowing Scroll when Focus Shifts Down Arrow Key Implementation Up Arrow Key Implementation Conclusion Introduction Up until now, all keyboard handling has been implemented with the default horizontal layout in mind. When display

Semantic HTML and Accessibility: Building Better Websites Introduction Semantic HTML is the practice of using HTML elements that clearly describe the purpose of the content on a webpage. Instead of using many <div> elements, semantic tags such as <header> , <nav> , <main> , <section> , <article> , and <footer> make the page easier to understand. Semantic HTML is important because it improves accessibility, helps search engines understand web pages, and makes code easier to read and maintain. Before: Non-Semantic HTML <div class= "header" > <h1> My Portfolio </h1> </div> <div class= "navigation" > <a href= "index.html" > Home </a> <a href= "about.html" > About </a> </div> <div class= "content" > <p> Welcome to my portfolio website. </p> </div> After: Semantic HTML <header> <h1> My Portfolio </h1> </header> <nav> <a href= "index.html" > Home </a> <a href= "about.html" > About </a> </nav> <main> <section> <p> Welcome to my portfolio website. </p> </section> </main> Accessibility Issues I Found 1. Images Missing Alternative Text Before: <img src= "images/profile.jpg" > After: <img src= "images/profile.jpg" alt= "Profile picture of Grace Loko" > Adding alternative text allows screen readers to describe images to users with visual impairments. 2. Navigation Was Not Semantic Before: <div> <a href= "index.html" > Home </a> <a href= "about.html" > About </a> </div> After: <nav> <a href= "index.html" > Home </a> <a href= "about.html" > About </a> </nav> Using the <nav> element helps assistive technologies identify the website navigation. 3. Form Inputs Had No Labels Before: <input type= "text" placeholder= "Your Name" > After: <label for= "name" > Name </label> <input type= "text" id= "name" name= "name" > Labels improve accessibility by helping screen readers identify each form field. Conclusion This accessibility audit helped me understand the importance of semantic HTML and accessible web design. By replacing non-semantic elements with semantic tags, adding image alt text,

An accessibility audit is not only a compliance activity. For engineering teams, it is also a quality review of how real users interact with the product. If you are preparing for a WCAG 2.2 AA audit, the biggest mistake is waiting for the auditor to tell you what information is missing. You can make the process much smoother by preparing the right workflows, accounts, test data, and remediation owners upfront. Scope the product by user flow Do not start with only a list of URLs. URLs matter, but accessibility bugs often appear inside stateful interactions: Form validation Custom dropdowns Modal dialogs Keyboard focus management Error recovery Dynamic tables Authenticated dashboards Document downloads Instead of asking, "Which pages should we test?" ask: What tasks must users be able to complete? That usually gives you a better audit scope. Prepare accounts and stable data If a workflow requires authentication, roles, or sample records, prepare them before the audit starts. Useful prep includes: Admin, standard user, and limited-role accounts Stable sample records Forms with prefilled data where needed Test payment or transaction flows if applicable Known feature flags Environment notes This avoids spending audit time debugging access problems. Confirm the standards WCAG 2.2 AA may be the target, but the report may also need to reference WCAG 2.1 AA, Section 508, EN 301 549, GIGW, or IS 17802. Engineering teams should know this early because it affects reporting language and remediation priority. Make evidence developer-friendly A useful issue should be reproducible. Good audit findings usually include: Affected URL or screen Component or selector Steps to reproduce User impact WCAG success criterion Expected behavior Screenshot or notes This helps teams move from report to ticket without guessing. Plan remediation ownership Accessibility issues do not always map cleanly to one discipline. Examples: Missing form label: engineering Confusing error copy: content and pr

Originally published on danholloran.me The original Grimicorn was an exercise in restraint: muted pastels on a blue-gray base, tuned so nothing on screen ever burns your eyes. Grimicorn Neon is the opposite impulse. Same grim-reaper-meets-unicorn idea, except this one is plugged into the mains — saturated, glowing accents on a near-black base, dark-only, loud on purpose. What makes the pair interesting from an engineering angle is how little had to change to get there. Neon is not a new theme so much as the same theme with the volume knob turned all the way up. That only works because of a decision made back in the calm version: colors are defined by role, not by appearance. Eight roles, eight louder hexes Both themes share the exact same role map. Blue is keywords, links, and the primary accent. Green is strings, success, and the cursor. Yellow is types, decorators, and warnings. The accent hierarchy is still blue → purple → teal, and the semantic anchors still hold: green means good, the error color means wrong. What changes is only the values bound to those roles. Calm Grimicorn's blue is a soft #83AFE5 ; Neon's is an electric #2323FF . Calm green is a sage #A9CE93 ; Neon green is an acid #A3E635 . The error role even swaps identity, from a gentle salmon to a hot #FF2D9B pink. Lay the two palettes side by side and the structure is identical — only the saturation and brightness move: // same eight roles, two personalities const calm = { blue : " #83AFE5 " , green : " #A9CE93 " , error : " #DD9787 " , base : " #253039 " , }; const neon = { blue : " #2323FF " , green : " #A3E635 " , error : " #FF2D9B " , base : " #0A0A0B " , }; Because every one of the fourteen tool ports — VS Code, Ghostty, Obsidian, Claude Code, JetBrains, tmux, and the rest — is generated from a single palette.md , producing the neon set was mostly a matter of feeding the build a different eight values. The emitters that translate roles into VS Code scopes or ANSI slots never knew the difference.

Why Semantic HTML is a Superpower for Your Website As I’ve been building my personal portfolio during the IYF Season 11 program, I realized that writing code is about more than just making things look "right"—it’s about making them accessible for everyone. The secret is Semantic HTML. What is Semantic HTML? Semantic HTML uses tags that provide meaning to the web page rather than just layout instructions. Tags like , , , , and tell the browser and screen readers exactly what content they are interacting with. If you use for everything, you are handing a screen reader a blank map. Semantic tags act like a GPS, allowing users with visual impairments to navigate your site efficiently. Before vs. After The difference is clear when comparing structure: Before (Non-Semantic): HTML My Portfolio Home | About | Contact Welcome to my site... After (Semantic): HTML My Portfolio Home About Contact Welcome to my site... Fixing Accessibility Issues During my accessibility audit (Task 2.3), I identified three key areas to improve: Missing alt Attributes: I had images without descriptions. I fixed this by adding context, such as alt="Portrait of Gladwell Muthoni, web development student", ensuring screen readers can describe images to visually impaired users. Lack of Semantic Structure: My initial gallery relied on generic containers. Switching to and tags organized my project list logically, helping assistive technology categorize the content. Heading Hierarchy: I was using tags for visual styling rather than logical structure. I corrected this to follow a strict to hierarchy, which helps screen readers outline the page properly. My portfolios URL https://github.com/gladwellmuthoni/iyf-s11-week-01-gladwellmuthoni.git

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. In my last development article , I finally completed the requirements for delivering an uncontrolled navigation component with a horizontal layout; with full keyboard functionality, along with adding the niceties of closing sublists when lists are closed and making sure any open sublist on the top row closes when focus shifts away from it. Rather than write an entirely new component for a mobile version, I'm going to modify the existing code. This first article outlines the steps necessary to set up and work with a controlled component. -— Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 1.0.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered across components, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for the Controlled Components Release along with previous requirements. Content Links Introduction Acceptance Criteria Contr

When I started learning web development, I discovered that creating a webpage is more than making it look good. It is also important to make websites accessible and easy for everyone to use. Two concepts that helped me improve my website were semantic HTML and web accessibility. Semantic HTML means using HTML elements according to their purpose instead of using generic elements for everything. Semantic elements such as , , , , , and make the structure of a webpage clear. They improve readability, help search engines understand the content, and make websites easier for people using screen readers. Before (Non-Semantic HTML) My Website Welcome to my website. After (Semantic HTML) <h1>My Website</h1> Welcome to my website. The semantic version is much easier to understand because each element clearly describes its purpose. During my accessibility audit, I found several improvements that made my website more user-friendly. The first issue was that images needed descriptive alternative text. I added meaningful alt attributes so screen readers can describe the images to users who cannot see them. The second improvement was the heading hierarchy. I used one for the page title and organized the remaining sections with headings. This creates a logical structure that is easier to navigate. The third improvement involved descriptive links. Instead of using vague text, I changed links to clearly describe where they lead. For example, I used "Visit GitHub" instead of a generic phrase. I also ensured that the HTML document included the lang="en" attribute and that all form fields had properly associated elements. These small changes improve accessibility and usability for everyone. Working with semantic HTML and accessibility has shown me that building websites is not only about appearance but also about creating experiences that everyone can use. As I continue learning web development, I will continue applying these best practices in all my projects. My Portfolio Portfolio Websi

Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 0.9.0 . A page showcasing these base components may be run locally through this release. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component.] The design requirements for this release are available . -— Content Links Introduction Layout Appearance <nav / > Generic Styling Reimagining Focus and Hover Achieving Parity aria-current Refinements Summary Introduction With only one more release coming up and the horizontal layout styling complete, now is the time to focus on completing vertical layout styling. Most of the layout itself was completed in an earlier release and described in the article Laying it all out on the vertical . When styling a component, care must be taken to ensure parity with the information provided by screen readers through some aria attributes. For instance, a navigation component must set the aria-current="page" attribute on a link whose href points to the current page. In the example being shown, the link in question is the "by Era" link, under Find Your Next Story and Tales. ) While screen reader users hear which button or link is the item currently capturing focus, styling is needed to achieve the same for screen users. Visual styling is necessary to guarantee that visual and auditory/tactile users have the same information. Layout @layer system-c

What is a Link? Definition A link is an interactive element that redirects the user to a new location which can be another section inside the current page, modifying the URL with a # parameter, or a new page. It can be used to download a file. Once activated, it takes the user to the URL set in its href. The browser records that navigation in its history, so the user can return to the previous page using the back button. Semantic The elements needs the attribute href with a valid URL or an IDREF pointing to a section inside the current page to have the semantic value of a link, otherwise it will be considered as generic . <a href= "/URL" > Go to main page </a> Keyboard Interaction It can only be activated by pressing the key Enter . If the key Space is pressed while the focus is on the link, the page will scroll down. Screen Reader Interaction Screen Readers, generally, announce the links in the following way: Link, [accessible name of the link] . It is extremely important to provide a descriptive and correct accessible name to the element. Bad Practice It is completely unnaceptable, a bad practice and goes against the native behavior of the element, forcing it to behave as a button by doing the following: <a href= "javascript:void(0)" onclick= "openModal()" > Open Menu </a> <a href= "#" role= "button" onclick= "button()" > Link with role button </a> If you need to do this, it means that you need a link. What is a button? Definition A button is an interactive element that dispatches an action inside the page where it is located. It does not redirect the user to another place or location nor modifies the url. The actions that are being dispatched can be: open a modal, play a video, post a comment, etc. Semantic The button needs the attribute type with a value according to its action: - type="button" : it is used when the button does not have a default behavior. - type="submit" : it is used when the button sends information to a server. - type="reset" : it is used to

¿Qué es un enlace? Definición Un link/enlace/elemento ancla es un elemento interactivo que redirecciona al usuario a una nueva ubicación la cual puede ser una página diferente, una ubicación distinta en la misma página (se modifica el URL en ese caso con un parametro # ) o también se puede utilizar para descagar un archivo, entre otras cosas. Al activarse, lleva al usuario a la URL definida en su href. El navegador guarda esa navegación en su historial, de modo que el usuario puede volver a la página anterior. Semántica Para que el elemento tenga carga semántica de elemento interactivo, tiene que si o si tener un atributo href con una URL válida o un IDREF que apunte a un elemento en la misma página, de lo contrario va a ser tratado como un elemento genérico . <a href= "/URL" > Ir a la página principal </a> Interacción con el teclado Solo se puede activar con la tecla Enter . Si se presiona la tecla Space mientras el foco esta en el enlace, la página va a scrollear hacia abajo. Interacción con lectores de pantalla Los lectores de pantalla, generalmente, anuncian el elemento de la siguiente manera: "Enlace, [Nombre accessible del enlace]" por lo cual es importante que el enlace tenga un nombre accesible pertinente y descriptivo. Malas prácticas Es totalmente inaceptable, una mala práctica y va en contra del funcionamiento nativo del elemento, forzar a un enlace a comportarse como un botón de la siguiente manera: <a href= "javascript:void(0)" onclick= "openModal()" > Abrir menu </a> <a href= "#" role= "button" onclick= "boton()" > Enlace con rol botón </a> Si necesitas hacerlo, quiere decir que necesitas un botón ¿Qué es un botón? Definición Un botón es un elemento interactivo que al ser cliqueado ejecuta una acción dentro de la página donde se encuentra. NO redirige al usuario a otro lugar, ni modifica la URL. Las acciones ejecutadas pueden ser abrir un modal, reproducir un vídeo, publicar un comentario, etc. Semántica El botón necesita el atributo type según la acci

We launched **GPSRReady on the Shopify App Store on June 8, 2026. It is a compliance app that helps Shopify merchants meet the EU General Product Safety Regulation (GPSR), which has been mandatory since December 2024 for non-food products sold in the EU. Two weeks later, here is the honest picture: organic rank above 96 on every relevant search term. The listing copy is solid. The app works. The installs are at zero. This post is about what the algorithm actually does to new apps — and what we are doing about it.** What GPSRReady does The EU General Product Safety Regulation entered into force in December 2024. For Shopify merchants selling non-food products to EU or UK consumers, it introduces mandatory product-level disclosures: the responsible person or importer, safety warnings, traceability information (batch number, serial, item number), and CE marking where applicable. GPSRReady surfaces these as native Shopify metafields and a theme block that auto-displays the right disclosures on every product page — no theme code injection, one-click uninstall. The EAA connection is close: both GPSR and the European Accessibility Act (EAA) are EU product and service regulations that enforce via the same channel — national market surveillance authorities — and both are often missed by non-EU merchants who think geography exempts them. They do not. If you sell into the EU above the microenterprise threshold, both regulations apply to your storefront. That is why we built both apps under the same umbrella. The ranking situation at day 14 On June 16 — day 8 post-launch — we ran a ranking check across the terms we are targeting. Results: gpsr : rank above 96 (not in the first 8 pages Shopify returns) gpsr compliance : rank above 96 product safety : rank above 96 eu representative : rank above 96 safety warnings : rank above 96 This is not a listing-copy problem. The description covers responsible person, importer, CE marking, traceability, labelling. The app title carries the

I’m building ScriptTap, a no-root Android automation app for user-controlled phone workflows. The app lets people create scripts with taps, swipes, routines, screen-aware checks, OCR/text detection, image/pixel checks, variables, logic, and AI-assisted script creation. The technical side is hard, but the trust side may be harder. ScriptTap needs Android Accessibility permission because user-authored input automation requires it. That is a powerful permission. I do not want to minimize it, hide it behind vague onboarding copy, or expect people to click through without understanding what they are enabling. That creates a product-design problem. If the copy is too soft, it feels dishonest. If the copy is too warning-heavy, a legitimate automation tool can feel suspicious before the user even understands what it does. The explanation I am trying to make clear is: ScriptTap is no-root. Scripts are created and controlled by the user. Screen capture is user-controlled. It does not bypass Android permissions, lock screens, app security, or consent flows. Accessibility is required for overlay/input automation, so users should understand why it is being requested. The short version I keep coming back to is: ScriptTap uses Accessibility so your scripts can interact with the screen the way you tell them to. This is a powerful permission. You should only enable it if you understand and trust what the app is doing. For developers who have built apps with sensitive permissions: How did you explain the permission without either hiding the risk or scaring users away from a legitimate feature?

Here's a question most businesses never think to ask when they're building a website: can everyone actually use this? Not just the people on a fast laptop with perfect vision and a reliable internet connection. Everyone. The person navigating your site with a screen reader because they're visually impaired. The user who can't use a mouse and relies entirely on a keyboard. The individual with a cognitive disability who needs clear, consistent layouts to make sense of what they're looking at. If your website doesn't work for these people, it doesn't work full stop. And yet, accessibility is almost always the last thing discussed in a web development project, usually buried somewhere at the bottom of a checklist, treated as a nice-to-have instead of a requirement. That needs to change. Not because of legal compliance (though that's a real consideration too), but because accessibility-first web development simply produces better websites. Faster load times, cleaner code, better SEO, higher user retention accessible design delivers all of that. The framework isn't complicated. It just requires thinking about it from the start instead of trying to bolt it on at the end. This is that framework. What Accessibility-First Web Development Actually Means Accessibility-first is a mindset, not a checklist. It means building with the full range of human experience in mind from day one not auditing for compliance after the site is already live. It's Not the Same as Compliance WCAG (Web Content Accessibility Guidelines) is the global standard for web accessibility. Most businesses know it exists. Very few understand what it actually requires or that meeting WCAG 2.1 AA standards isn't a ceiling, it's a floor. Compliance means you passed the audit. Accessibility-first means you thought about disabled users during architecture decisions, during design reviews, during content writing, and during QA. Compliance is a document. Accessibility-first is a process. The gap between the two mat

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. My last development article completed the base requirements for keyboard functionality within the component; attention now shifts to adding some of the last functionality required, closing sublists when the lists holding them now close and determining what happens when a closed component is entered via the keyboard through the Tab and Shift+Tab keys. Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 0.8.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for the Focus and Refinement Support Release along with previous requirements. Content Links Introduction Acceptance Criteria Entering Closings Setting Up For Success Introduction The implementation of keyboard handling left one obvious keyboard issue to fix: an apparent keyboard trap that occurs when focus shifts into the component

Accessibility affects how millions of people interact with websites, applications, and digital services every day. Yet many digital experiences still create barriers for users with visual, auditory, cognitive, or motor impairments. To address this, organizations rely on the Web Content Accessibility Guidelines (WCAG) , the most widely recognized standard for building accessible digital products. WCAG provides a framework for designing, developing, and testing experiences that are usable by a broader range of people, regardless of ability. In this guide, we'll explore what WCAG compliance means, how the guidelines are structured, the different conformance levels, and the steps organizations can take to build more accessible digital experiences. What Is WCAG Compliance? WCAG compliance means a website, application, or digital product satisfies the accessibility requirements defined by the Web Content Accessibility Guidelines (WCAG) . These requirements are organized into testable success criteria that help organizations evaluate whether their digital experiences can be accessed and used by people with a wide range of abilities and assistive technologies. Compliance is typically measured against one of three conformance levels: A, AA, or AAA , with Level AA being the most commonly adopted standard. Who Created and Maintains WCAG? WCAG is developed and maintained by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI) . The W3C is the international standards organization responsible for many of the technologies and best practices that power the web. Through the WAI, it publishes and updates accessibility standards that help organizations create more inclusive digital experiences. WCAG vs. WCAG Conformance: What's the Difference? These two terms are often used interchangeably, but they refer to different concepts. > WCAG refers to the accessibility guidelines themselves. > WCAG conformance refers to the degree to which a website, application