标签：#a11y

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

Computer-based assessments have a quiet accessibility problem. Most platforms assume the user can read text on a screen, click through options, and type their responses. For visually impaired students — particularly in India — this assumption effectively shuts them out entirely. I wanted to fix that. Not with a workaround, but with an experience that feels native to voice from the ground up. The Problem Screen readers exist, but they're clunky, require separate setup, and often mispronounce Indian names, words, and sentence structures in ways that feel jarring and unnatural. The experience breaks down fast. What visually impaired Indian students actually need is a system that speaks to them the way people around them speak — in a familiar accent, at a natural pace, without sounding like a robot reading out a manual. That's what led me to Sarvam AI. Why Sarvam I had tried other TTS APIs before. They worked, technically. But there was always something off — a flatness to the voice, a slightly Western lilt, a pronunciation of common Hindi-origin words that made it obvious the model had never really heard Indian English spoken naturally. Sarvam's TTS was different. The first time I ran a test question through it, the output sounded like something a real person would say. The accent was warm and familiar — the kind of voice an Indian student would actually trust and follow without friction. That moment changed how I thought about the project. This wasn't just a convenience feature anymore. It was the core of the experience. What I Built The platform is a full-stack web app built with React and Tailwind on the frontend, Express.js on the backend, and PostgreSQL for storing user data and scores. The interaction model is deliberately simple. A single click anywhere on the screen triggers Sarvam TTS to read the current question aloud. A double click starts listening and transcribes the user's spoken answer using Sarvam STT. No keyboard required. No mouse precision required.

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 covered using an array of navigation objects to determine conditions and shift focus between components. This article covers Tab Key navigation. 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.7.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 the useNavigation hook, 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 Tab Handling Keyboard Release along with previous requirements. Content Links Introduction Acceptance Criteria Tab Key Handling Link Button Shift+ Tab Key Handling Link Button Introduction As I've mentioned in earlier articles, keyboard handling has two disparate audiences: those who can see the screen and those who rely on a screen reader. The arrow, home and end keys, for the most part, rely on a user knowing where they are and being able to discern where they wan

Originally published on danholloran.me There's a moment every CSS developer knows: you want to tweak a single property based on some condition — a viewport width, a user preference, a custom property — and instead of a clean one-liner you end up with a whole new @media block, duplicated selectors, and maybe a dash of JavaScript to handle the edge cases. It works, but it never feels right. The CSS if() function changes that. Shipping in Chrome 137, it brings inline conditional logic directly into your property declarations, letting you express branching style logic without leaving the property itself. How if() Works The syntax is a sequence of condition-value pairs, evaluated top to bottom until one matches: property : if ( condition : value ; else : fallback ); The function supports three types of conditions: style() — queries computed CSS custom property values media() — runs an inline media query supports() — feature-detects a CSS property or syntax You can chain them with else : button { padding : if ( media ( width >= 1024px ): 0.5rem 1.5rem ; else : 0.75rem 1.25rem ); } That's a responsive padding rule with zero extra @media blocks. Three Practical Uses 1. Touch-Friendly Targets with media() The pointer media feature lets you distinguish mouse users from touchscreen users. The accessible minimum tap target is 44px; mouse users can get away with smaller: .icon-button { width : if ( media ( any-pointer : fine ): 32px ; else : 44px ); height : if ( media ( any-pointer : fine ): 32px ; else : 44px ); } Previously this needed a full @media (any-pointer: coarse) block. Now it reads like what it is — a single property with two states. 2. Theme Switching with style() Custom properties are often used to carry design tokens — theme flags, component variants, status values. The style() query lets you branch on them inline: .status-badge { --status : pending ; background : if ( style ( --status : complete ): #22c55e ; style( --status : error ): #ef4444 ; else : #f59e0b );

As I'm observing engineers, I notice that most of them share the same characteristic: unending loads of curiosity. You, software developers, are deeply interested in how things work underneath; you implement, break, troubleshoot, fix, and break again. You create apps that people use everyday and by doing so, you shape the digitalised world we live in today. Now let me share something personal: I am terrified of breaking things. I am often terrified to such an extent that I find it hard to breathe. I am suffering from something called Generalised Anxiety Disorder (GAD), which basically means I am allergic to uncertainty. While most people see trying something new as exciting, for me it's a source of stress. Every unknown step, every unfamiliar process, every situation where I don't know what comes next — it triggers something. My brain immediately goes to the worst-case scenarios. "I can't do this." "I'll do it wrong." "What if something breaks?" These thoughts don't just pop up and disappear — they pile on top of each other until they become paralyzing. But this story isn't about anxiety — it's about how good UX can change a moment from overwhelming to manageable. And how you, as a software developer, can make a real change for people who are struggling. The app that saved my day A few months ago I decided to change my mobile operator. The alternative offer had much better terms that sounded really appealing to me. No long-term contract, competitive prices, support for eSIM for travellers abroad – in short: very flexible. Head held high, I went to the new operator's office to ask them to transfer my number. But the agent quickly wiped the smile off my face. "Yes, this offer is flexible, but you need to do all the operational work yourself in the app. I can only offer you a regular long-term contract," he said. He gave me my new SIM card, and I, with a long face, went to the nearby cafe. The thought that I had to transfer my number myself felt daunting. "What if I do

Forms are everywhere in mobile apps - authentication flows, data entry, support requests, onboarding... If your app has a login screen, a form is likely the first thing a new user interacts with. That makes accessibility here not just a nice-to-have, but a first impression. The problem is that forms are consistently one of the most broken areas for assistive technology users. Missing labels, keyboard traps, silent validation errors, focus going nowhere after submission - these are issues that make an app unusable for a significant portion of your users. This guide is a complete reference for building forms that work for everyone in React Native, whether users are navigating with their fingers, an external keyboard, a screen reader or voice input. Code examples throughout show both what to do and why . A fully working demo repo is available to fork and test on a real device - check it out at rn-accessible-form-demo . Labels Every form field needs a label, whether a text input, checkbox or radio/submit buttons. No exceptions. Don't rely on placeholders Placeholder text disappears the moment a user starts typing. Screen readers will read it initially, but once it's gone, there's no way for them to recall what the field was for without clearing their input. Placeholders are useful as hints, not as labels. Use a visual label + accessibilityLabel To avoid screen readers announcing the same information twice (once for the visual label, once for the input), hide the visual label from assistive technology and put the full label on the input itself. < Text importantForAccessibility = "no" accessibilityElementsHidden > Email address* </ Text > < TextInput accessibilityLabel = "Email address, required" /> importantForAccessibility="no" handles Android, and accessibilityElementsHidden handles iOS. Together they tell assistive technology to skip the visual label entirely - the accessibilityLabel on the TextInput is the single source of truth for screen readers. Required fields De

Co to jest WCAG 2.1? WCAG 2.1 ( Web Content Accessibility Guidelines ) to międzynarodowy standard techniczny określający, jak tworzyć strony www i aplikacje mobilne, aby były dostępne dla osób z niepełnosprawnościami (wzroku, słuchu, ruchu, poznawczymi). Wersja 2.1 rozszerza wcześniejsze zasady o wytyczne dla urządzeń mobilnych oraz osób słabowidzących. Struktura WCAG 2.1 i poziomy zgodności Standard opiera się na 4 głównych zasadach. Dzielą się one na wytyczne, do których przypisane są konkretne kryteria sukcesu wdrażane na trzech poziomach: Poziom A: Absolutne minimum. Bez niego strona jest całkowicie niefunkcjonalna dla wielu użytkowników. Poziom AA: Standard rynkowy i prawny. Wymagany przez polskie i europejskie przepisy dla sektora publicznego i biznesu. Poziom AAA: Najwyższy stopień dostępności, trudny do wdrożenia w całym serwisie. Zasady POUR – Fundamenty WCAG 2.1 Wszystkie wytyczne WCAG 2.1 opierają się na czterech głównych zasadach tworzących akronim POUR : P erceivable ( Postrzegalność ) - Treść musi być dostarczana w sposób czytelny dla zmysłów użytkownika (wzroku, słuchu). O perable ( Funkcjonalność ) - Interfejs i nawigacja muszą być możliwe do obsługi za pomocą różnych urządzeń (np. samej klawiatury). U nderstandable ( Zrozumiałość ) - Informacje oraz obsługa strony muszą być jasne, logiczne i przewidywalne. R obust ( Solidność ) - Kod strony musi być poprawny i kompatybilny z obecnymi oraz przyszłymi technologiami (przeglądarki, czytniki ekranu). Kto musi spełniać standardy WCAG? Dostępność cyfrowa to już od dawna nie tylko "dobra praktyka", ale twardy wymóg prawny, który stale się rozszerza: Sektor publiczny (Obecnie): W Polsce urzędy państwowe i samorządowe, szkoły, uczelnie, szpitale oraz spółki skarbu państwa mają bezwzględny obowiązek spełniania standardu WCAG 2.1 na poziomie AA. Wynika to wprost z Ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej . Za brak zgodności grożą kary finansowe. Sektor prywatny i biznes: Na mocy Europejskiego Akt

Keyboard accessibility is one of the most important — and most neglected — aspects of web accessibility. An estimated 2.5 million Americans have motor disabilities that prevent mouse use. If your site can't be operated entirely by keyboard, you're excluding them completely. The Four Core Principles WCAG 2.2 Principle 2 (Operable) contains the keyboard requirements: 2.1.1 Keyboard (AA): All functionality must be operable via keyboard 2.1.2 No Keyboard Trap (AA): If focus moves into a component, it must be possible to move it out 2.4.3 Focus Order (AA): If page can be navigated sequentially, order must be logical and predictable 2.4.7 Focus Visible (AA): Any keyboard-operable UI must have a visible focus indicator 2.4.11 Focus Appearance (AA, new in 2.2): Focus indicator must meet size and contrast requirements Testing Without Automated Tools Start with the basic keyboard test: Unplug (or ignore) your mouse Press Tab to move forward through interactive elements Press Shift+Tab to move backward Use Enter/Space to activate buttons, links, checkboxes Use arrow keys for radio groups, menus, sliders Use Escape to close dialogs and menus Any element you can't reach or activate? That's a WCAG 2.1.1 failure. The Most Common Keyboard Failures Custom dropdowns and menus // ❌ Keyboard inaccessible function Dropdown ({ items }) { return ( < div onClick = { toggle } className = "dropdown" > { items . map ( item => ( < div onClick = { () => select ( item ) } > { item . label } </ div > )) } </ div > ); } // ✅ Fully keyboard accessible function Dropdown ({ items }) { return ( < div role = "combobox" aria-haspopup = "listbox" aria-expanded = { isOpen } tabIndex = { 0 } onKeyDown = { handleKeyDown } // handles Enter, Space, Arrows, Escape className = "dropdown" > < ul role = "listbox" > { items . map (( item , i ) => ( < li key = { item . id } role = "option" tabIndex = { - 1 } aria-selected = { i === activeIndex } onKeyDown = { e => e . key === ' Enter ' && select ( item ) } > { item