# a11y Published articles for a11y. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Can AI Write Accessible Code? DevFeed: [Can AI Write Accessible Code?]() Original publisher: [Read original article]() Author: ashokyadav1231 Published: 2026-10-19T18:50:05Z Content type: article Language: en Sources: [SitePoint]() Topics: [Web Content Accessibility Guidelines](), [AI tools for developers](), [User interface design](), [aria]() Tags: [a11y](), [accessibility](), [accessible](), [ai](), [ai-generated-code](), [audit](), [auditing](), [authentication](), [autocomplete](), [automated](), [axe](), [axe-core](), [behavior](), [button](), [ci](), [code](), [write]() ### AI overview The article's audit concludes that GitHub Copilot can produce accessible code, but accessibility-aware prompts mainly improve markup; focus handling, interaction behavior and newer WCAG 2.2 criteria often remain incomplete. It compares neutral and accessibility-aware prompts across five UI areas and recommends a repeatable review: automated axe checks plus manual keyboard, screen reader and zoom testing, since automated scans catch only some issues. Examples include using native buttons with labels and adequate target sizes, associating form errors with fields, managing modal focus, keeping focused content clear of sticky headers, offering button alternatives to dragging, and allowing password and one-time-code paste. Repository instructions, specific behavior-focused prompts, linting, CI checks and human review provide practical guardrails, while results may vary by model, context and wording. ### Source excerpt null Continue reading Can AI Write Accessible Code? on SitePoint. ## BrowserStack Recognized as a Challenger in the 2026 Gartner® Magic Quadrant™ for Digital Accessibility DevFeed: [BrowserStack Recognized as a Challenger in the 2026 Gartner® Magic Quadrant™ for Digital Accessibility]() Original publisher: [Read original article]() Author: BrowserStack Team Published: 2026-10-19T10:54:23Z Content type: news Language: en Sources: [BrowserStack Blog]() Topics: [Web Accessibility (a11y)](), [AI in frontend development](), [CI/CD Pipeline]() Tags: [a11y](), [accessibility-testing](), [ai-agent](), [shift-left]() ### AI overview BrowserStack reports its recognition as a Challenger in the 2026 Gartner Magic Quadrant for Digital Accessibility. It describes accessibility testing integrated into design tools, IDEs and CI/CD pipelines, real-device screen reader automation, continuous scanning, and a beta AI agent that tests user journeys using screen readers. ### Source excerpt BrowserStack has been recognized as a Challenger in the 2026 Gartner® Magic Quadrant™ for Digital Accessibility. Discover how we're transforming accessibility into a continuous, automated workflow with real-device testing and shift-left developer tools. ## EPUB 3.4 adds roll layouts and updates accessibility and media support DevFeed: [EPUB 3.4 adds roll layouts and updates accessibility and media support]() Original publisher: [Read original article]() Author: Wendy Reid, W3C Publishing Maintenance Working Group Invited Expert Published: 2026-10-12T17:06:00Z Content type: release Language: en Sources: [W3C]() Topics: [Internationalization (i18n)](), [aria]() Tags: [a11y](), [accessibility](), [aria](), [blogs](), [digital-publishing](), [documentation](), [w3c]() ### AI overview W3C's Publishing Maintenance Working Group describes the candidate EPUB 3.4 update, including a vertical roll layout for digital comics, additional media types and codecs, accessibility metadata changes, and features marked outdated or deprecated. EPUBCheck 5.4.0 adds checks for the new specification. Existing EPUB files that conform to earlier versions remain compatible. ### Source excerpt The Publishing Maintenance Working Group at W3C has been quietly working on yet another update for the EPUB3 standard, and we're excited to share what we have been up to. Our goal is to not only maintain the EPUB standard, but do our best to keep it in line with the needs of industry, and this update does exactly that. Your existing books do not need to change, if they conform to previous EPUB versions, they will conform to EPUB 3.4. Content you create today will automatically conform as well. ## Designing Accessible Keyboard Focus States With CSS DevFeed: [Designing Accessible Keyboard Focus States With CSS]() Original publisher: [Read original article]() Author: Ilknur Published: 2026-09-27T17:45:36Z Content type: tutorial Language: en Sources: [HackerNoon]() Topics: [Web Content Accessibility Guidelines](), [aria](), [Front end]() Tags: [a11y](), [accessibility](), [accessible](), [accessible-design](), [code](), [css](), [css-accessibility](), [developer](), [focus](), [focus-indicators](), [frontend-development](), [keyboard](), [removing-css-focus-outlines](), [wcag](), [wcag-2-2](), [web-accessibility]() ### AI overview The article explains why visible keyboard focus outlines matter for accessibility, how removing them can make navigation difficult, and what WCAG says about keyboard access and visible focus. It discusses the impact on people who navigate without a mouse and points to accessible ways to style focus states. ### Source excerpt Removing CSS focus outlines can make keyboard navigation difficult or impossible. Here's what WCAG requires and how to style focus states accessibly. ## Testing A11y Using Cypress And wick-a11y Plugin DevFeed: [Testing A11y Using Cypress And wick-a11y Plugin]() Original publisher: [Read original article]() Author: Gleb Bahmutov Published: 2026-04-07T04:00:00Z Content type: tutorial Language: en Sources: [Gleb Bahmutov]() Topics: [Cypress](), [Web Accessibility (a11y)](), [Software Testing](), [Web app](), [Continuous integration]() Tags: [a11y](), [accessibility](), [app](), [browser](), [ci](), [color](), [cypress](), [errors](), [html](), [install](), [plugin](), [products](), [reports](), [test](), [testing](), [tests](), [web-app]() ### AI overview A tutorial on adding accessibility testing to the Gametime web app with Cypress and the wick-a11y plugin. It covers plugin setup, checking for readable text, labeled inputs, landmarks, severity levels, and detailed HTML reports that can be saved as CI artifacts. ### Source excerpt I have a little web app called Gametime I use to keep track of players during youth socc ## How a Learning Project Became Our Modern Mobile Test Framework DevFeed: [How a Learning Project Became Our Modern Mobile Test Framework]() Original publisher: [Read original article]() Author: Raymond Saba I'm an SDET who enjoys building test automation; Finding Ways Published: 2026-02-18T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Test automation](), [Mobile](), [mobile-app-performance]() Tags: [a11y](), [accessibility](), [android](), [android-testing](), [appium](), [architecture](), [automation](), [collaboration](), [compatibility](), [configuration](), [dependencies](), [deprecated](), [engineering](), [framework](), [java](), [learning](), [mobile](), [modern](), [project](), [quality-assurance](), [test](), [upgrade]() ### AI overview An Appium 1 learning project grew into the team's primary framework for shared iOS and Android testing after an older homegrown setup could not handle Java and dependency upgrades. The Appium 2 transition prompted a rewrite around W3C WebDriver standards and platform-specific drivers, with modular plugins that can hook into any test lifecycle phase. The new framework runs parallel scenarios in threads within one JVM rather than separate JVM forks, reducing startup and memory overhead while retaining less process-level isolation. Dedicated platform plugins separate iOS and Android behavior; reusable plugins handle logging, reporting, configuration, and session management. The team also made accessibility IDs and testability part of feature design, then used end-to-end tests to check accessibility labels, values, screen-reader attributes, and cross-platform behavior. The authors say this reduced flakiness and maintenance costs and helped the framework move to Appium 3 without another ground-up rebuild. ### Source excerpt About six years ago, our mobile automation setup was showing its age. It was a small, homegrown framework that had worked "well enough" for a long time, until we tried to upgrade Java and a few ... ## How we are using AI in Mercado Libre's accessibility team DevFeed: [How we are using AI in Mercado Libre's accessibility team]() Original publisher: [Read original article]() Author: Martín Di Luzio Published: 2025-10-08T12:58:25Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [Web Accessibility (a11y)](), [AI in frontend development](), [Artificial Intelligence](), [ai code review](), [AI Chat](), [Retrieval Augmented Generation (RAG)](), [AI Integration Strategies](), [UI/UX Design](), [User interface design](), [Large Language Model](), [Web Content Accessibility Guidelines](), [Figma]() Tags: [a11y](), [accessibility](), [ai](), [also](), [approach](), [artificial-intelligence](), [artificial-intelligence-ai](), [audits](), [automate](), [automation](), [automatization](), [avoid](), [better](), [but](), [can](), [capacity](), [libre](), [mercado](), [team](), [using]() ### AI overview Mercado Libre's accessibility team uses AI to extend support across design and development while keeping answers tied to internal standards and expert review. Its A11Y assistant responds when mentioned in a support channel, processes messages and screen images, and uses RAG over internal documentation, training, prior queries and tickets, and the design system. AI also adds user impact, suggested fixes, and verification steps to manual audit tickets, and enriches Axe findings with context. For design handoffs, an assistant analyzes desktop or mobile screen images and proposes text annotations; responses remain text-only because they are more accurate than image-based annotations. A Jira, GitHub, and AI workflow reviews resolved tickets, checks comments and linked pull requests, rates fix quality, and records results to help prioritize manual review. The team presents these tools as a way to increase team autonomy and reserve accessibility experts' time for strategic work, not replace them. ### Source excerpt AI isn't here to replace accessibility work -- it's here to make it stronger. Today, our accessibility team faces a challenge: supporting hundreds of designers and developers with questions, reviews, and continuous improvements. To scale this impact, we're exploring how artificial intelligence (AI) can help us automate tasks, provide immediate answers, and foster collective learning. That's why we've launched several initiatives to speed up work, increase independence, and strengthen execution capacity. Note: In many of these initiatives, we rely on automatization tools available in our internal development ecosystem, Fury. The A11Y assistant for everyday workImage 1: Automation flow that integrates different nodes, from the user's question to obtaining relevant information, processing it, and providing an answer.How does it work? This assistant: Activates when mentioned in the support channel. Processes both messages and screen images. Consults internal documentation, training materials, historical queries, previously reported accessibility tickets, and our design system. Uses a large language model (LLM) with Retrieval-Augmented Generation (RAG) to deliver reliable answers. The result: contextualized responses grounded in internal resources and standards. From the query initiation to gathering additional context, and finally to delivering a response backed by verified information, the entire pipeline is crucial. This approach helps avoid "hallucinations" (invented or incorrect answers) and ensures the A11Y assistant stays focused on trusted resources. Thus, it provides solutions and resources that are not only accurate but also directly applicable and aligned with Mercado Libre's internal accessibility standards and tools. Understanding problems better to deliver better solutions One of our biggest learnings is that teams need information that's clear and easy to understand -- not just technical reports. In manual accessibility audits, we provide technical details s ## Open sourcing the GitHub Annotation Toolkit DevFeed: [Open sourcing the GitHub Annotation Toolkit]() Original publisher: [Read original article]() Author: Allison Published: 2025-09-22T20:14:32Z Content type: release Language: en Sources: [GitHub Changelog]() Topics: [Figma](), [User interface design](), [Open Source](), [GitHub]() Tags: [a11y](), [accessibility](), [accessible](), [annotation](), [annotation-toolkit](), [canvas](), [design](), [details](), [diagram](), [figma](), [github](), [helps](), [library](), [open](), [open-source](), [source](), [system](), [this](), [toolkit](), [ui]() ### AI overview GitHub's open source Annotation Toolkit is a Figma library for documenting accessibility details during design handoff, aiming to prevent issues before development. It supports canvas and flow notes, UI structure, interactions, controls, forms, media, focus and reading order, system feedback, and iOS and Android annotations. Interactive checklists help designers and engineers track WCAG considerations; Primer A11y Presets provide examples for GitHub components. GitHub reports that 48% of its audited accessibility issues could have been prevented in design. The toolkit is intended for both specialists and newcomers, with documentation, tutorials, and handoff guidance. Figma variables allow teams to adapt layouts and visual styles. It is available through GitHub and Figma Community under CC-BY-4.0, with attribution to the CVS Health Inclusive Design team. ### Source excerpt GitHub's Annotation Toolkit is now available as an open source Figma library. This comprehensive annotation system helps you organize your design canvas, diagram your UI anatomy, and annotate accessibility details.... ## VIDEO: Thunderbird Accessibility Study DevFeed: [VIDEO: Thunderbird Accessibility Study]() Original publisher: [Read original article]() Author: Monica Ayhens-Madon Published: 2025-09-05T15:14:54Z Content type: article Language: en Sources: [The Thunderbird Blog]() Topics: [Web Accessibility (a11y)](), [Mobile](), [User interface design](), [App](), [aria](), [W3C]() Tags: [a11y](), [accessibility](), [accessible](), [community](), [desktop](), [inclusive](), [keyboard](), [mobile-apps](), [office-hours](), [screen](), [study](), [thunderbird](), [video]() ### AI overview A Community Office Hours video examines Thunderbird's accessibility study for its desktop and mobile apps. The study used assistive technology evaluations and moderated interviews to identify accessibility barriers, including inconsistent keyboard shortcuts, confusing search and filter workflows, and screen-reader issues. ### Source excerpt Welcome back to another edition of the Community Office Hours! This month, we're taking a closer look at accessibility in the Thunderbird desktop and mobile apps. We're chatting with Rebecca Taylor and Solange Valverde, members of our designer, about a recent accessibility (often shortened as a11y) study. We wanted to find out where Thunderbird was [...] The post VIDEO: Thunderbird Accessibility Study appeared first on The Thunderbird Blog. ## Bluesky Likes Web Components DevFeed: [Bluesky Likes Web Components]() Original publisher: [Read original article]() Author: Lea Verou Published: 2025-06-17T00:00:00Z Content type: article Language: en Sources: [Lea Verou's blog]() Topics: [Web Components](), [API](), [Bluesky](), [Web]() Tags: [a11y](), [api](), [api-design](), [article](), [blog](), [bluesky](), [components](), [i18n](), [launch](), [open-source](), [web-components](), [web-standards]() ### AI overview The author presents web components for displaying Bluesky post likes and discusses the practical challenges of building accessible, localizable components that consume public API data. The article highlights Bluesky's open API, which allows unauthenticated access to public data without an API key. ### Source excerpt Just want the components? Here you go: Demo Repo NPM A love letter to the Bluesky API I'm old enough to remember the golden Web 2.0 era, when many of today's big social media platforms grew up. A simpler time, when the Web was much more extroverted. It was common for websites to embed data from others (the peak of mashups), and prominently feature widgets from various platforms to showcase a post's likes or shares. Especially Twitter was so ubiquitous that the number of Twitter shares was my primary metric for how much people were interested in a blog post I wrote. Then, websites started progressively becoming walled gardens, guarding their data with more fervor than Gollum guarding the Precious. Features disappeared or got locked behind API keys, ridiculous rate limits, expensive paywalls, and other restrictions. Don't get me wrong, I get it. A lot of it was reactionary, a response to abuse -- the usual reason we can't have nice things. And even when it was to stimulate profit -- it is understandable that they want to monetize their platforms. People gotta eat. I was recently reading this interesting article by Salma Alam-Naylor. The article makes some great points, but it was something else that caught my eye: the widget of Bluesky likes at the bottom. Salma's Bluesky likes widget that inspired these I mentioned it to my trusty apprentice Dmitry who discovered the API was actually much simpler than what we've come to expect. Later, it turned out Salma has even written an entire post on how to implement the same thing on your own site. The openness of the API was so refreshing. Not only can you read public data without being authenticated, you don't even need an API key! Major nostalgia vibes. It seemed the perfect candidate for a web component that you can just drop in to a page, give it a post URL, and it will display the likes for that post. I just had to make it, and of course use it right here. Web Components that use API data have been historically awkward. Let ## GitHub CLI 2.72.0 DevFeed: [GitHub CLI 2.72.0]() Original publisher: [Read original article]() Published: 2025-04-30T19:59:18Z Content type: release Language: en Sources: [GitHub CLI]() Topics: [GitHub CLI extension](), [Web Accessibility (a11y)](), [GitHub]() Tags: [a11y](), [accessibility](), [changelog](), [configuration](), [contribution](), [environment](), [environment-variables](), [error](), [features](), [feedback](), [github](), [github-cli](), [json](), [release](), [repo]() ### AI overview GitHub CLI 2.72.0 introduces a public preview of accessibility improvements, including customizable contrasting colors, non-interactive prompts, and text-based spinners. The release also adds a `gh accessibility` help topic, supports a JSON field in `gh pr view`, and includes fixes to prompts and error output. ### Source excerpt ## :accessibility: Accessibility public preview This release marks the public preview of several accessibility improvements to the GitHub CLI that have been under development over the past year in partnership with our friends at [Charm](https://github.com/charmbracelet) including: - customizable and contrasting colors - non-interactive user input prompting - text-based spinners These new experiences are captured in a new `gh a11y` help topic command, which goes into greater detail into the motivation behind each of them as well as opt-in configuration settings / environment variables. We would like you to share your feedback and join us on this journey through one of [GitHub Accessibility feedback channels](https://accessibility.github.com/feedback)! 🙌 ## What's Changed ### ✨ Features * Introduce `gh accessibility` help topic highlighting GitHub CLI accessibility experiences by @andyfeller in https://github.com/cli/cli/pull/10890 * [gh pr view] Support `closingIssuesReferences` JSON field by @iamazeem in https://github.com/cli/cli/pull/10544 ### 🐛 Fixes * Fix expected error output of `TestRepo/repo-set-default` by @aconsuegra in https://github.com/cli/cli/pull/10884 * Ensure accessible password and auth token prompters disable echo mode by @andyfeller in https://github.com/cli/cli/pull/10885 * Fix: Accessible multiselect prompt respects default selections by @BagToad in https://github.com/cli/cli/pull/10901 ## New Contributors * @aconsuegra made their first contribution in https://github.com/cli/cli/pull/10884 **Full Changelog**: https://github.com/cli/cli/compare/v2.71.2...v2.72.0 ## Item Flow DevFeed: [Item Flow]() Original publisher: [Read original article]() Author: Ahmad Shadeed Published: 2025-04-12T00:00:00Z Content type: article Language: en Sources: [Ahmad Shadeed]() Topics: [CSS](), [layout](), [web-standards]() Tags: [a11y](), [css](), [css-grid](), [display](), [flexbox](), [gap](), [layout](), [padding](), [property](), [syntax]() ### AI overview This article examines the proposed CSS Item Flow system for unifying grid, flexbox, and masonry-related layout behavior. It discusses how the proposal could enable masonry through CSS syntax and explores dense packing options for flexbox, including potential accessibility concerns from reordering. ### Source excerpt Notes on the proposed Item Flow system for grid, flexbox, and masonry ## On compliance vs readability: Generating text colors with CSS DevFeed: [On compliance vs readability: Generating text colors with CSS]() Original publisher: [Read original article]() Author: Lea Verou Published: 2024-05-17T00:00:00Z Content type: tutorial Language: en Sources: [Lea Verou's blog]() Topics: [CSS](), [color](), [Web Development]() Tags: [a11y](), [blog](), [browser](), [color](), [color-science](), [colors](), [compliance](), [css](), [readability](), [standards](), [web-standards]() ### AI overview This article examines how to emulate the upcoming CSS contrast-color() function using widely shipped CSS features, especially Relative Color Syntax. It explains the tradeoffs between automatically choosing readable text colors and meeting contrast requirements, with attention to browser support and production fallbacks. ### Source excerpt Can we emulate the upcoming CSS contrast-color() function via CSS features that have already widely shipped? And if so, what are the tradeoffs involved and how to best balance them? Relative Colors Out of all the CSS features I have designed, Relative Colors aka Relative Color Syntax (RCS) is definitely among the ones I'm most proud of. In a nutshell, they allow CSS authors to derive a new color from an existing color value by doing arbitrary math on color components in any supported color space: --color-lighter: hsl(from var(--color) h s calc(l * 1.2)); --color-lighterer: oklch(from var(--color) calc(l + 0.2) c h); --color-alpha-50: oklab(from var(--color) l a b / 50%); The elevator pitch was that by allowing lower level operations they provide authors flexibility on how to derive color variations, giving us more time to figure out what the appropriate higher level primitives should be. As of May 2024, RCS has shipped in every browser except Firefox. but given that it is an Interop 2024 focus area, that Firefox has expressed a positive standards position, and that the Bugzilla issue has had some recent activity and has been assigned, I am optimistic it would ship in Firefox soon (edit: it shipped 5 days after writing these lines, in Firefox 128 🎉). My guess it that it would become Baseline by the end of 2024. Even if my prediction is off, it already is available to 83% of users worldwide, and if you sort its caniuse page by usage, you will see the vast majority of the remaining 17% doesn't come from Firefox, but from older Chrome and Safari versions. I think its current market share warrants production use today, as long as we use @supports to make sure things work in non-supporting browsers, even if less pretty. Most Relative Colors tutorials revolve around its primary driving use cases: making tints and shades or other color variations by tweaking a specific color component up or down, and/or overriding a color component with a fixed value, like the example above ## 5 tips for making your GitHub profile page accessible DevFeed: [5 tips for making your GitHub profile page accessible]() Original publisher: [Read original article]() Author: Annie Streater Published: 2023-10-26T16:00:24Z Content type: tutorial Language: en Sources: [GitHub Blog]() Topics: [User interface design](), [Web Content Accessibility Guidelines](), [GitHub](), [CI/CD]() Tags: [a11y](), [accessibility](), [accessible](), [alt-text](), [dev-tools](), [developer-skills](), [developer-tools](), [developers](), [github](), [open-source](), [readme]() ### AI overview The article offers practical ways to make a GitHub profile README more accessible, including writing descriptive links and alt text, using clear heading and list structure, and limiting emoji. It also recommends accessibility tools and shows how to run Markdown checks with GitHub Actions. ### Source excerpt Your profile's README invites the world to know you and your work, so it's important that everyone can read and understand it. In this post, we share some tips for making your README more accessible. ## What's new in Svelte: May 2023 DevFeed: [What's new in Svelte: May 2023]() Original publisher: [Read original article]() Author: Dani Sandoval Published: 2023-05-01T00:00:00Z Content type: article Language: en Sources: [Svelte]() Topics: [Svelte](), [changelog](), [Vite](), [ESLint](), [Hackathon]() Tags: [a11y](), [announcements](), [changelog](), [community](), [embedded](), [eslint](), [hackathon](), [svelte](), [vite]() ### AI overview A May 2023 Svelte newsletter covering new Svelte and SvelteKit features, compiler and language-tool updates, Vite integration changes, and a new official ESLint plugin. It also announces Svelte Ambassadors, previews SvelteHack results, and showcases projects built with Svelte and related tools. ### Source excerpt Before we dive into the updates, there's a few announcements worth mentioning at the top: New Svelte Ambassadors Regular features of this newsletter and all-around great content creators for Svelte JoyOfCode and HuntaByte have been appointed as Svelte Ambassadors. Ambassadors are people who are well known for their helpfulness and contributions and for upholding Svelte's reputation as a friendly, welcoming community, and we're deeply grateful for their involvement! SvelteHack winners will be announced May 6th In a just a few days, we'll find out who won SvelteHack - the Svelte Hackathon that took place between February 17th and April 17th. Tune in to Svelte Summit on May 6th to see if your favorite project was chosen 👀 Lots of submissions to the hackathon are featured in this month's showcase... but first, let's see what's new! What's new in Svelte style blocks now support CSS @container queries (3.58.0) bind:innerText is now available for contenteditable elements (3.58.0) A new accessability warning, a11y-interactive-supports-focus will now warn when interactive elements are not focusable (3.58.0) For all the changes to the Svelte compiler, including unreleased changes, check out the CHANGELOG. What's new in SvelteKit When hot module reloading (HMR) is enabled, the page will reload after an error is fixed (1.14.0, #9497) Two apps loaded into the same html page can now be loaded simultaneously in "embedded" mode (1.15.7, #9610) Vite's compilation will now log warnings for packages that use the svelte field to resolve Svelte files differently than standard Vite resolve (vite-plugin-svelte@2.1.0, kit@1.15.8) What's new in Language Tools Support for (#1958) and intellisense report for new bindings (#1957) (107.3.0) The new fix-all menu option for the "Quick fix..." makes it easy to "Add all missing imports" and other detected errors (107.3.0, #1939) We have a new and better official ESLint plugin! Previous support for Svelte in ESLint did not handle t ## Contrast Ratio has a new home -- and this is great news! DevFeed: [Contrast Ratio has a new home -- and this is great news!]() Original publisher: [Read original article]() Author: Lea Verou Published: 2023-03-18T00:00:00Z Content type: release Language: en Sources: [Lea Verou's blog]() Topics: [User interface design](), [User Experience](), [open source maintenance](), [Web Development](), [Open Source]() Tags: [a11y](), [alpha](), [app](), [blog](), [books](), [color](), [colors](), [contrast-ratio-com](), [css](), [css-color](), [css-wg](), [developers](), [domain](), [formats](), [future](), [great](), [guidance](), [hex](), [hsl](), [it](), [iteration](), [news](), [ratio]() ### AI overview Contrast Ratio calculates WCAG 2.1 contrast ratios for CSS colors. Its creator designed it for CSS editing, supporting semi-transparent colors with a calculated ratio range, accepting CSS color formats such as HSL for direct editing, and making ratio calculation quick to support iteration. After maintaining it largely through pull requests due to other commitments, the creator transferred the domain to Ross and Drew of Siege Media, who committed to taking over maintenance of the open source project. The creator says their plans give the tool a brighter future. ### Source excerpt It has been over a decade when I launched contrast-ratio.com, an app to calculate the WCAG 2.1 contrast ratio between any two CSS colors. At the time, all similar tools suffered from several flaws when being used for CSS editing: No support for semi-transparent colors (Since WCAG included no guidance for alpha transparency -- I had to do original research to calculate the contrast ratio range for that case) No support for color formats other than hex or (at best) RGB with sliders. I wanted something where I could just paste a CSS color just like I had it specified in my code (e.g. hsl(220 10% 90%), possibly tweak it a bit to pass, then paste it back. I didn't want to use unintuitive hex colors, and I didn't want to fiddle with sliders. Poor UX, often calculating the actual ratio required further user actions, making iteration tedious Over the years, contrast-ratio.com grew in popularity: it was recommended in several books, talks, and workshops. It basically became the standard URL developers would visit for this purpose. However, I've been too busy to work on it further beyond just merging pull requests. My time is currently split between the dozens of open source projects I have started and maintain, my TAG work, my CSS WG work, and my teaching & research at MIT. Therefore, when Ross and Drew from Siege Media approached me with a generous offer to buy the domain, and a commitment to take over maintainship of the open source project, I was cautiously optimistic. But now, after having seen some of their plans for it, I could not be more certain that the future of this tool is much brighter with them. Please join me in welcoming them to the project and help them get settled in as new stewards! ETA: Siege Media Press Release ## Accessibility insights. How to make the most of Android's accessibility features. DevFeed: [Accessibility insights. How to make the most of Android's accessibility features.]() Original publisher: [Read original article]() Author: Pradeep Kumar HK. Published: 2022-10-14T15:28:31Z Content type: tutorial Language: en Sources: [ymedialabs-innovation]() Topics: [Web Accessibility (a11y)](), [inclusive design](), [User interface design](), [Android Testing](), [Software Testing](), [Android]() Tags: [a11y](), [accessibility](), [accessibility-testing](), [android](), [everyonematters]() ### AI overview Android apps can improve accessibility by supporting assistive tools and making screen-reader navigation clearer. TalkBack reads focused content, Magnification zooms the screen, and Switch Access supports navigation without touch. Developers can find issues by exploring with these tools, reviewing Android Studio Lint warnings, running Espresso accessibility checks, or scanning screens with Accessibility Scanner; the text notes Robolectric accessibility testing was removed in version 4.5. Use contentDescription for unlabeled images and buttons, or mark nonessential views to be skipped. Group related content with focusable attributes, connect labels to individually focusable inputs with labelFor, and set traversal order where needed. For design, make clickable targets at least 48dp and use at least a 3:1 text contrast ratio. The text presents these as basic measures and points to Google's accessibility checklist for further guidance. ### Source excerpt Note : Accessibility (often abbreviated to A11y -- as in, "a", then 11 characters, and then "y") Improving your product's a11y can enhance the usability for all users, including those with low vision, blindness, hearing impairments, cognitive impairments, motor impairments or situational disabilities (such as a broken arm). You may have experienced difficulties using your phone while wearing gloves when it's cold outside. Maybe you've had a hard time distinguishing items on the screen when it's bright outside. Most people will have at least a short term disability at some time that makes it difficult to use their mobile device. This includes someone who was born blind, or lost fine motor skills in an accident. With so much of the population experiencing decreased vision, hearing, mobility, and cognitive function, you should do your best to give everyone the best experience in your apps. In this write up, we are going to discuss ways we can make Android app more accessible, and by the end of this you will know the most basic ways you can improve your app for a11y. You will learn: Available a11y tools people are using. How to discover existing a11y issues, and prevent a11y regression. Android attributes you can use to make your app more accessible. Design guidelines to allow your user to use your app with ease. A11y tools : Assistive technology helps increase, maintain, or improve the functional capabilities of individuals with disabilities, through devices like screen readers, magnification tools, and hearing aids. There are many tools that people use to interact with their Android devices. This includes TalkBack, Magnification, and Switch Access, to name a few. TalkBack allows you to explore the view using gestures, while also audibly describing what's on the screen.Magnification allows you to zoom in on parts of the screen. Both TalkBack and Magnification are helpful for people with limited visibility.People with limited mobility can use Switch Access to allow them ## What is the best way to mark up an exclusive button group? DevFeed: [What is the best way to mark up an exclusive button group?]() Original publisher: [Read original article]() Author: Lea Verou Published: 2022-07-14T00:00:00Z Content type: article Language: en Sources: [Lea Verou's blog]() Topics: [Web Accessibility (a11y)](), [User interface design](), [Web Development](), [aria](), [Document Object Model (DOM)]() Tags: [a11y](), [accessibility](), [aria](), [articles](), [blog](), [button](), [discussion](), [implementation](), [ux](), [web-accessibility](), [web-components]() ### AI overview A discussion of how to mark up an exclusive button group in a web component. It examines the accessibility and user-experience tradeoffs between buttons and radio buttons, including ARIA state, grouping, Shadow DOM, and ElementInternals. ### Source excerpt A few days ago I asked Twitter a seemingly simple question (I meant aria-pressed, not aria-selected but Twitter doesn't allow edits...): https://twitter.com/LeaVerou/status/1545712667515654144 For background, I was implementing a web component for an app I'm working on at work and I was getting into some pretty weird rabbit holes with my approach of generating radios and labels. Unsurprisingly, most people thought the best solution is radio buttons and labels. After all, it works without CSS, right? Progressive enhancement and everything? That's what I thought too. I had contorted my component to generate labels and radios in the Shadow DOM from buttons in the light DOM, which resulted in awkward code and awkward CSS, but I felt I was fighting the good fight and doing the best thing for accessibility. All this was challenged when the actual accessibility expert, Léonie Watson chimed in. For those of you who don't know her, she is pretty much the expert when it comes to web accessibility and standards. She is also visually impaired herself, giving her a firsthand experience many other a11y aficionados lack. Her recommendation was contrary to what most others were saying: https://twitter.com/LeonieWatson/status/1545745436740313089 She went on to make the point that if a design looks like buttons, it should act like buttons, otherwise there are mismatched expectations and poor UX for AT users: https://twitter.com/LeonieWatson/status/1545762058339319808 https://twitter.com/LeonieWatson/status/1545757022645325824 In case you were wondering if state would be equally noticeable with aria-pressed and buttons, it is: https://twitter.com/LeonieWatson/status/1545763493412052992 And some advice on grouping: https://twitter.com/LeonieWatson/status/1545745923011117057 In theory doing this in Shadow DOM and/or using ElementInternals implicit roles should be fine, though in practice we've had some trouble with that. Today I posted my attempt to implement what we've discussed in a ) Original publisher: [Read original article]() Author: Federico Monaco Published: 2021-10-09T00:00:00Z Content type: article Language: en Sources: [The A11Y Project]() Topics: [color](), [UI/UX Design](), [Web Accessibility (a11y)](), [User interface design]() Tags: [a11y](), [accessible](), [application](), [career](), [color](), [colors](), [community](), [consoles](), [design](), [designer](), [designers](), [digital](), [digital-products](), [experience](), [green](), [information](), [interfaces](), [internet](), [manifesto](), [product]() ### AI overview The designer says deuteranomaly made color-dependent interfaces harder to use, leading them to prefer products that do not rely on color alone. At work, adjacent Post-it colors can become indistinguishable, and vague requests such as "more blue" are insufficient; they need exact color codes and context about what shades should convey. They tell coworkers about their colorblindness, use sampled colors from screenshots, favor high contrast, and treat color as decoration rather than the sole carrier of information. They also seek feedback from other designers on how colors may appear to people without colorblindness. The excerpt mentions a ten-rule accessibility manifesto but does not include its rules. ### Source excerpt Colorblindness is any visual anomaly where someone has an altered perception of colors. It can be total or partial. The A11Y Project already has an article that exhaustively covers the different types of color blindness while also providing tools that you can use during your design phases. In this article, I'd like to tell you what it means to be a colorblind designer and what the main problems are that someone with colorblindness can encounter if they decide to pursue a career as a designer. Colorblindness from a user's point of view During elementary school, like most colorblind people, I discovered that I have deuteranomaly, the most common form of colorblindness: I have a deficit in the sensitivity of my green color receptors. In my offline life, it's never caused me too much inconvenience, other than the strange color combinations of my clothes. Growing up and during my introduction to the internet and the first video-game consoles, I encountered more barriers than I had expected. From then on, I started using special filters if an application offered them, and I preferred to browse sites that didn't over rely on color alone to convey information. Recently, I was pondering whether most people with colorblindness had problems online or whether I was one of the few people to experience that. Through deep user research I found two interesting answers: the first is that I wasn't the only person with colorblindness to have problems online; the second is that, unfortunately, I found many more people than I had imagined. In light of this, I decided to write a manifesto of ten rules that all designers should follow to create digital products that are more accessible to the colorblind community. Working as a colorblind designer In addition to being a colorblind internet user, I am also a colorblind designer. This part of me comes into play when I have to design digital interfaces, either alone or as part of a team. When I'm part of a team, I immediately let people know ## a11y and a brief numeronyms primer DevFeed: [a11y and a brief numeronyms primer]() Original publisher: [Read original article]() Author: Scott O'Hara Published: 2017-08-26T00:00:00Z Content type: article Language: en Sources: [The A11Y Project]() Topics: [Web Accessibility (a11y)](), [Internationalization (i18n)](), [Localization (l10n)]() Tags: [a11y](), [accessibility](), [article](), [comment](), [computer](), [examples](), [hash](), [help](), [html](), [i18n](), [inclusive](), [international](), [l10n](), [localization](), [number](), [numbers](), [primer](), [virtualization](), [w3c](), [web]() ### AI overview "a11y" abbreviates "accessibility" by keeping the first and last letters and replacing the 11 letters between them with the number 11. The text distinguishes numeronyms from ordinary abbreviations and acronyms, and gives examples including i18n, l10n, and W3C. Because "a11y" may be unclear or resemble "ally," it recommends spelling out "accessibility" where possible and explaining the shorthand when introducing it. It notes that the tag can be useful on space-limited platforms, while typefaces, spell checkers, autocorrect, and mobile keyboards can create confusion or typing friction. ### Source excerpt If you're unfamiliar with the term "numeronym", you may not have realized that a11y isn't just a hash tag, nor is it a hip way to spell ally. Rather a11y is a shorthand for accessibility. You may have seen "a11y" used as a hash tag on Twitter, or used in a comment, article, used in a comment thread, or written in an article. Since you're reading this right now, you've likely seen it in the name of a certain website about accessibility. Ahem... How numeronyms work Unlike abbreviations like FYI (for your information), and PC (personal computer), or acronyms like HTML (hypertext markup language), and JAWS (Job Access With Speech), numeronyms are number-based words. And while you may not be familiar with the term "numeronym" itself, you've likely used them throughout your life. For instance, "9-1-1" is synonymous with "help", "24/7" means "24 hours a day, 7 days a week", and Y2K is for "year 2000" or "the year 2000 problem." These are all examples of numeronyms. As illustrated by the previous numeronyms, sometimes they're used to replace entire words with numbers, or they use a combination of letters and numbers to combine words. In the case of a11y, Adrian Roselli explains: Skip embedded Tweet. Tip: "a11y" is a numeronym for accessibility. Keep first & last letter, between them put the count of letters removed -- in this case eleven. -- aardrian (@aardrian) November 22, 2016 Other numeronyms The following is a short list of numeronyms you may have seen, or even used, but didn't know what they were called. i11l international i18n internationalization l10n localization n7m Numeronym v12n Virtualization W3 World Wide Web W12t Web Development W3C World Wide Web Consortium Back to a11y While numeronyms have been around for quite some time, they're not always immediately understandable. As a defining trait of accessibility is about being inclusive, one should keep the following in mind when using a11y: If you can say or write "accessibility", do so! A11y (often pronounced "A-o ## It's Not About Morals: Accessibility is for the Masses DevFeed: [It's Not About Morals: Accessibility is for the Masses]() Original publisher: [Read original article]() Published: 2016-06-01T00:00:00Z Content type: article Language: en Sources: [Una Kravets]() Topics: [Web Accessibility (a11y)](), [Web](), [User interface design]() Tags: [a11y](), [accessibility](), [aria](), [language](), [screen](), [web]() ### AI overview The article argues that accessibility benefits the majority of users, not only people with disabilities. It discusses semantic markup and ARIA roles, screen readers, and clear language as practical ways to make web products easier for everyone to use. ### Source excerpt Accessibility is often solely discussed in terms of people with disabilities, but in truth, it's something that benefits the majority (if not all) of your users. ## Easy color contrast ratios DevFeed: [Easy color contrast ratios]() Original publisher: [Read original article]() Author: Lea Verou Published: 2012-10-14T00:00:00Z Content type: article Language: en Sources: [Lea Verou's blog]() Topics: [Web Accessibility (a11y)](), [CSS](), [Web Development](), [Algorithms](), [W3C]() Tags: [a11y](), [accessibility](), [algorithm](), [blog](), [browser](), [colors](), [contrast-ratio-com](), [css](), [releases](), [wai](), [wcag]() ### AI overview An accessibility-focused article examines WCAG color contrast ratios and explains why the author built a tool to evaluate CSS colors, including semi-transparent colors, more conveniently. ### Source excerpt I was always interested in accessibility, but I never had to comply with any guidelines before. At W3C, accessibility is considered very important, so everything we make needs to pass WCAG 2.0 AA level. Therefore, I found myself calculating color contrast ratios very frequently. It was a very enlightening experience. I used to think that WCAG-mandated contrast ratios were too restrictive and basically tried to force you to use black and white, a sentiment shared by many designers I've spoken to. Surprisingly, in practice, I found that in most cases they are very reasonable: When a color combination doesn't pass WCAG, it usually *is* hard to read. After all, the possible range for a contrast ratio is 1-21 but only ratios lower than 3 don't pass WCAG AA (4.5 if you have smaller, non-bold text). So, effectively 90% of combinations will pass (82.5% for smaller, non-bold text). There are plenty of tools out there for this. However, I found that my workflow for checking a contrast ratio with them was far from ideal. I had to convert my CSS colors to hex notation (which I don't often use myself anymore), check the contrast ratio, then adjust the colors as necessary, covert again etc. In addition, I had to adjust the lightness of the colors with a blindfold, without being able to see the difference my adjustments would make to the contrast ratio. When using semi-transparent colors, it was even worse: Since WCAG only describes an algorithm for opaque colors, all contrast tools only expect that. So, I had to calculate the resulting opaque colors after alpha blending had taken place. After doing that for a few days, I got so fed up that I decided to make my own tool. In addition, I discovered that there was no documented way of calculating the contrast ratio range that can be produced with a semi-transparent background, so I came up with an algorithm (after many successive failures to find the range intuitively), published it in the w3c-wai-ig mailing list and used the algorit