DEV Community: Mica

Accessible and Functional Quantity Spinbutton Pattern

Mica — Wed, 02 Sep 2026 20:42:40 +0000

Hey! This is Mica writing, a human not an AI agent (nothing against them, not discrimination of any kind is allowed here). Just a brief disclaimer before starting: this post was non AI-generated (I am not going to lie, I tried to use it for some research but since the errors I found were not properly documented the AI invented answers, lol) because I felt the urgent need to start using my brain and hands to craft something from scratch. If you are a human, let's connect, at the end you will find the ways to reach me. I am on a doom scrolling detox so you won't find me on instagram or twitter now. So, I have a question: Is there anybody out there?

Introduction

If you work on an e-commerce, a booking (hotels, flights, trains, etc) platform, a restaurant reservation system maybe you are familiar with the quantity spinbutton component. It is a common UI pattern that allows users to select a quantity of items they want to purchase or book. It is configured by two buttons and one input; one button for increasing the quantity, another button to decrease the quantity and an input where the user is able to type the desired amount or increase/decrease the quantity using the Up Arrow or Down Arrow accordingly. Sounds simple, and yes it is, but it is also a critical flow in the user journey. If it's badly implemented, you can not only be potentially losing sales (translation: losing money, which is important) but also creating a frustrating experience for users with disabilities (which should be more important than money, but those are my morals and ethics, lol). My goal in this article is setting a clear basis of a non-negotiable structure and behavior of the quantity spinbutton pattern and from there, explore different variations depending on the use case.

Disclaimer: This is not a written-in-stone guide, I can make mistakes, so please let me know if you disagree with something.

Expected behaviors

Keyboard

Key	Action
Up Arrow	Increases the value by its step value
Down Arrow	Decreases the value by its step value
Home	If the spinbutton has a minimum value, sets the value to its minimum
End	If the spinbutton has a maximum value, sets the value to its maximum
Command or Fn + Right Arrow	Substitute for Apple's keyboards that do not have a End key to set the value to its maximum
Command or Fn + Left Arrow	Substitute for Apple's keyboards that do not have a End key to set the value to its minimum

Screen Readers

NVDA Navigation

You can download NVDA here and it's only available for the Windows operating system. It is compatible with Chrome, Firefox and Edge browsers.
Long story short, an NVDA modifier key is needed to navigate using this screen reader. The modifier key can be Insert key (by default) or it can be remapped to the Caps Lock in the settings. Two modes for different purposes can be found:

Browse Mode: Browse mode is used when reading documents or web pages.
Focus Mode: Focus mode is used when the user enters a form or other fields that require user input.

NVDA automatically switches between Browse and Focus modes, but the user can toggle them using Insert + Space Bar.

Command	Task
Down Arrow (Browse Mode)	Read next item
Enter or Space Bar	Activate button
Down Arrow (Focus Mode)	Decrement by step
Up Arrow (Focus Mode)	Increment by step
Home	Jump to aria-valuemin (via your custom handler)
End	Jump to aria-valuemax (via your custom handler)
Tab	Commit value, leave the field, return to browse mode

VoiceOver Navigation

If you are a macOS user, VoiceOver comes built into the operating system of your MacBook. It's compatible with the Safari browser.
VoiceOver uses the Control and Option keys before each command. This combination is called VO and these keys can be locked/unlocked by pressing Control + Option + ;(semicolon) all together.

Command	Task
Tab/Shift + Tab	Go to next/previous focusable item (link, button, input, etc.)
VO + Space Bar	Activate a link or form control
VO + Right Arrow	Move VO cursor to next element (not limited to focusable items)
VO + Left Arrow	Move VO cursor to previous element
VO + Shift + Down Arrow	Once the VO cursor is on the spinbutton, this combination enters the spinbutton
Up Arrow	Once inside the spinbutton, increment by step
Down Arrow	Once inside the spinbutton, decrement by step
Home	Jump to aria-valuemin (via your custom handler)
End	Jump to aria-valuemax (via your custom handler)

Gestures VoiceOver - iOS

If you are an iOS user, VoiceOver is the screen reader by default on the operating system of your iPhone. It's compatible with the Safari browser. Unlike VoiceOver on macOS, VoiceOver on iOS, the navigation is controlled by finger gestures.

Gesture	Task
Swipe next	Read next item
Swipe left	Read previous item
Double-tap	Activate (link, button)
Swipe up	If the VO cursor is over the spinbutton, increase the value
Swipe down	If the VO cursor is over the spinbutton, decrease the value

Gestures Talkback - Android

If you are an Android user, TalkBack is the default screen reader on the operating system of your mobile. It's compatible with Chrome, Firefox and Edge. Like VoiceOver for iOS, the navigation is controlled by gestures with the fingers.

Gesture	Task
Swipe next	Read next item
Swipe left	Read previous item
Double-tap	Activate (link, button)
Swipe up	If the VO cursor is over the spinbutton, increase the value
Swipe down	If the VO cursor is over the spinbutton, decrease the value

Pattern A: APG (ARIA Authoring Practices Guide) Spinbutton by W3C

Currently everyone is following the APG (ARIA Authoring Practices Guide) as if it were the bible and not as what it is: a guide, a very useful guide, btw, THE guide. Everything written there is considered a commandment written in stone by non-accessibility experts (the people behind W3C are doing an amazing work and I only have gratitude and admiration towards them) and this might be a problem. The intention is good but the execution is not. When you first land on the APG Spin Button Pattern, the first thing you see is an alert with the following warning:

The code in this example is not intended for production environments. Before using it for any purpose, read this to understand why.

and then a list of reasons why you should be critical of the pattern provided. In this case, the most important one is:

Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heeding the warning that No ARIA is better than Bad ARIA.

So, what does this mean? Well, a couple of important things:

Always be critical of everything (a rule for life, tho)
Keep in mind the necessities and limitations of your product/business, and (more importantly) comply with the regulations and legislation in order to guarantee freedom of navigation through your product for users with disabilities.
There is always (well, almost 80% always) an HTML equivalent.

After this brief introduction to the APG, I would like to dive into its Spinbutton pattern. W3C (The World Wide Web Consortium) presents us a solution using the WAI-ARIA role="spinbutton" on the input tag instead of using the native HTML solutions provided by the tag itself, the buttons are removed from the focus flow because they have a tabindex="-1" but they are still operable via mouse and by using screen readers. Only the tag with the role="spinbutton" is not fully semantic by itself and we will need to add the keyboard and screen reader functionalities programmatically and make it semantic by adding properties and states to the input element.

In the accessibility field we have a mantra: No ARIA is better than Bad ARIA. You should be extra careful when using ARIA because, if it is not used correctly, you will end up creating more issues than solving them. Again, the intention is good but the outcome is more barriers. Last month, WebAIM org launched its annual report for 2026 about the state of accessibility in over 1 million pages: The WebAIM Million. The report shows that in 2026, accessibility errors increased by 10.1% according to the WCAG 2.2 Level A/AA conformance failures and concluded with the following reflection:

The 2026 WebAIM Million analysis found notable increases in both the number of detected accessibility errors and number of pages with WCAG conformance failures, reversing a trend of gradual accessibility improvements in recent years. A primary concern is the significant increase in home page complexity and ARIA code, both of which correlate to increased detectable errors. These trends likely reflect broader shifts in web development including increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices (“vibe coding”). Home pages are getting larger and more technologically complex at an alarming rate, making accessibility more difficult to achieve and maintain. A key takeaway from this year's report is improving accessibility at scale will require both better practices and simpler systems. Alternatively, complex systems need to do a better job of focusing on accessibility fundamentals.

It's not a surprise that creating components using AI without questioning the output will end up creating more barriers for users with disabilities, and sloppier websites overall. Also, the lack of native and accessible examples on the web makes the AI coding agents return inaccessible components, but okay not everything is the fault of the AI, to be honest.

Functional Example – APG

you can find the functional example here

APG code

<input 
  id="add-to-bag"
  role="spinbutton"
  type="text"
  inputMode="numeric"
  pattern="[0-9]*"
  autoComplete="off"
  spellCheck="false"
  aria-valuemin={MIN}
  aria-valuemax={MAX}
  aria-valuenow={isValid ? numeric : undefined}
  aria-valuetext={value}
  aria-invalid={!isValid || undefined}
  aria-describedby={isValid ? 'help-add-to-bag' : 'help-add-to-bag error-add-to-bag'}
  value={value}
  onChange={handleChange}
  onKeyDown={handleKeyDown}
/>

id: to relate the <input /> with the <label> element
role="spinbutton": this is a WAI-ARIA role that allows the user to increase and decrease a value within a given range. This role can be used on <input> or on a non-semantic element such as <div>. The APG pattern for the spinbutton component proposes the <input> with a type="text" making the development more challenging. The expected keyboard behavior for a spinbutton is being able to increment or decrement the value by pressing the up/down arrow accordingly. Since this is not a native interaction of the role="spinbutton" or of the <input type="text" />, we have to programmatically cover these behaviors. The spinbutton element with type text generally comes with two buttons (one for decrement and the other to increment the value) that should be excluded from the navigation flow by adding tabIndex={-1}.
type="text": implies that the spinbutton will receive a value of type text, which is a pain because it means that we have to transform the type text to type number later.
inputMode="numeric": since the input is type text, we have to make the browsers know which virtual keyboard they will have to display. This is vital for mobile navigation because without the value numeric the virtual keyboard display to enter a value will be a QWERTY instead of a numeric input keyboard.
pattern="[0-9]*": again, since the input is type="text", we have to use a regex to only admit values of type number. (This attribute was not on the APG example, but I cannot help myself).
autocomplete="off": it is used on inputs that take a text or numeric value as input to prevent the browser from automatically entering a value into this field. (again, my take, not on APG example).
aria-valuemin="[NUMBER]": sets the minimum value allowed for the spinbutton. The default is 0, if no value is passed.
aria-valuemax="[NUMBER]": sets the maximum value allowed for the spinbutton. The default is 100, if no value is passed.
aria-valuenow="[number]": here things start to get interesting. By definition, this attribute defines the current value for a range widget (meter, scrollbar, slider and spinbutton). Since we are not using a semantic solution, this value should be updated programmatically. Also, this value is intended for numeric values and APG provides an example where the spinbutton is being considered as a text, so we have to also transform the value from type string to type number. This is not everything! Since the spinbutton is not correctly typed, the announcement of the current value will be done as a percent by VoiceOver (macOS and iOS) announces it as a percent, TalkBack on Pixel 10 does not announce it at all, and NVDA announces it correctly. You can test it on the APG example.
aria-invalid="[boolean]": indicates that the current value is invalid.
aria-describedby="[IDREF]": this attribute is used to establish a relationship between widgets or groups and the text that describes them.

Conclusion for the APG Spinbutton Pattern

To articulate a conclusion for this pattern, I drew on Core Accessibility API Mappings 1.2 which is a guide that specifies how WAI-ARIA roles, states, and properties are expected to be exposed by user agents (browsers, in this case) via platform accessibility APIs.

Since a spinbutton is considered a range widget, it's implicitly expected to receive a value of type number even though the APG pattern tells us otherwise. By implementing a role spinbutton in a text input, we will be going against the nature of the role, which leads us to do extra work to make it work correctly.
The pattern is good but we can make it better, with some browser limitations (the party can never be enjoyed in peace), with the native HTML solution as we will see below.

Pattern B: Native HTML solution

Unfortunately, nothing is perfect; the native HTML solution for spinbutton is tempting because it works well in most cases BUT has a few limitations that aren't HTML-related but browser-related, buuuh.

Browsers have different engines to create what we colloquially know as Accessibility Tree. This tree is just an object with nodes. Every node includes information about the HTML elements and attributes. Finally, this object is being exposed to the Accessibility APIs of every operating system so they can translate the information and make it readable to assistive technologies. Here is where the things get complicated because every browser engine sometimes interprets things differently. Below, you can find a list of the browser engines for the different browsers and the Accessibility APIs they support.

Blink: this is the browser engine for Chrome, Edge, Opera and Brave (all browsers based on Chromium) which means all the browsers are going to have the same Accessibility Tree as the one we can see on the following image:

Supported on the following Accessibility APIs:

Windows: IAccessible, IAccessible2 and UIAutomation
Mac: NSAccessibility (funny thing here is that Blink creates a more accurate and complete node than WebKit and VoiceOver announces the spinbutton better on Chrome, as we are going to read later)
Linux: ATK
Android: AccessibilityNodeInfo and AccessibilityNodeProvider. I opened a ticket for this operating system because it is not exposing the spinbutton correctly preventing the user from having an accessible experience. The ticket to Android can be seen here
- Gecko: this is the browser engine for Firefox. The Accessibility Tree it creates, in my opinion, is the most complete and it is compatible with the following Accessibility APIs:
Windows: IAccessible, IAccessible2 and UIAutomation
Mac: mozAccessible
Linux: ATK
- WebKit: this is the browser engine for Safari in macOS and iOS. Here is where our problems start. The engine does not recognize the element as a spinbutton but as a role="textbox" if we don't explicitly pass the role="spinbutton" to the <input type="text" />. This is an issue because the VoiceOver screen reader in both devices, desktop and mobile, will prevent the user from having an accessible experience, the same issue that I faced on Android. Again, I ended up opening a ticket to Apple about this behavior. The ticket to Apple can be seen here

Functional Example – HTML

The native functional example can be found here

HTML native code

<input 
  id="add-to-bag-native"
  type="number"
  role="spinbutton"
  autoComplete="off"
  min={MIN}
  max={MAX}
  step={STEP}
  value={value}
/>

id: same thing as in the APG pattern
type="number": this is what natively converts an input into a spinbutton and restricts it to numeric values. It natively supports supports increasing and decreasing the value by: pressing the native controls that come with the input type="number" (see/read/perceive the image below), pressing Up Arrow or Down Arrow, or swiping (on mobile with the screen readers on).

The appearance of these arrows inside the input comes by default and we can override it if we provide another mechanism to substitute the buttons themselves; we already did that with the custom buttons to increase and decrease the value, so we are good to go.

  input[type="number"] {
    appearance: textfield;
  }

  input[type="number"]::-webkit-outer-spin-button,
  input[type="number"]::-webkit-inner-spin-button {
    -webkit-appearance: none;
    margin: 0;
  }

appearance: textfield;, we need it to strip the native spinbutton styling in Firefox
::-webkit-outer-spin-button and ::-webkit-inner-spin-button are pseudo-selectors that only Blink and WebKit recognize and the -webkit-appearance: none property strips the native spinbutton styling in Chrome and Safari.
- role="spinbutton": well, having in mind all the compatibility issues we have in different browsers, I found out that if you only pass the WAI-ARIA role="spinbutton" magically they all disappear. So, there is no harm in adding it to prevent headaches in the future. This post was built for this moment, you can thank me.
- autoComplete="off": just the same as in the APG example
- min={NUMBER}: the minimum value to accept for this input and should be less than or equal to the maximum value. If a value that isn't a valid number is specified, then the input has no minimum.
- max={NUMBER}: the maximum value to accept for this input and should be greater than or equal to the minimum value.
- step={NUMBER}: defines the allowed interval between valid values. The default is 1 and only accepts integers.
- value={NUMBER}: a number representing the value of the number entered into the input

Conclusion for the HTML native solution

If you want to have a functional, accessible and widely supported across browsers spinbutton component, I recommend using my solution and to always go to the native solutions and, if you do not feel comfortable enough, talk to your trustworthy accessibility expert. This native example with the workaround of adding a WAI-ARIA role="spinbutton" to force its semantic value on some browser engines was tested on:

Chrome (version 148) + macOS (Tahoe version 26.4.1) + VoiceOver
Chrome (version 148) + iOS (version 26.4.1)/ iPhone pro 15 + VoiceOver
Chrome (version 148) + Windows 11 + NVDA
Chrome (version 148) + Android/Pixel 10 (version 16) + TalkBack
Firefox (version 150) + Windows 11 + NVDA
Firefox (version 150) + macOS (Tahoe version 26.4.1)
Safari (version 26.4) + macOS (Tahoe version 26.4.1) + VoiceOver
Safari (version 26.4) + iOS (version 26.4.1) + VoiceOver

What I did not cover but it's important to mention: the Home and End keyboard shortcuts mentioned on the Keyboard section are not provided natively so you have to cover them programmatically. Also, some keyboards, such as Apple's keyboards (always Apple) do not have keys for Home and End and they are substituted by the combination Command or or Fn + Right/Left Arrows so you have to cover this combination as well. It's just a function of a 9-line function, nothing too exceptional, you should contemplate it.

  const handleKeyDown = (ev: KeyboardEvent<HTMLInputElement>) => {
    if (ev.key === 'End' || (ev.metaKey && ev.key === 'ArrowRight')) {
      ev.preventDefault()
      setValue(MAX)
    } else if (ev.key === 'Home' || (ev.metaKey && ev.key === 'ArrowLeft')) {
      ev.preventDefault()
      setValue(MIN)
    }
  }

Final Thoughts

Having a semantic, functional and accessible spinbutton on your e-commerce will not only contribute to improving the overall internet experience to everyone but it will leverage your product and increase your sales. A win-win for all parties involved; you get the money, the user, no matter how he/she/they are navigating, gets the product.
According to WHO more than 2.5 billion people need one or more assistive products to to meet their daily needs, and one of those needs is the right to navigate freely through the web. You do not really know who is navigating through your website behind the screen, could be a human with different needs or now an AI AGENT (!!!!). Omg, a new party entered the game and should be contemplated too. Nowadays, some users are relying on autonomous purchase bots, voice shopping assistants or AI browsing agents. These AI assistants base their navigation on the web in the same way as any other assistive technology: they consume the data provided by the Accessibility Tree. Amazing.

Well, we learned that: a new player entered the game (AI assistants), the native HTML solution is always the best option (might be buggy but it's the browser's fault) and you should always be critical and test everything you are building.

You can find me on:

email: micaela.avigliano@gmail.com
linkedin: https://www.linkedin.com/in/micaelaavigliano/

HTML tags that will improve your e-commerce experience

Mica — Tue, 01 Sep 2026 09:42:58 +0000

Understanding when to use `<ins>`, `<del>` and `<s>` HTML tags

Comparative Feature	`<ins>` element	`<del>` element	`<s>` element
Semantic Definition	Represents the content that has been added to a document.	Represents a range of text that has been deleted from a document.	Represents content that is no longer accurate, correct, or relevant.
Use Case	New edits in a code, in a text, tracked changes	Document edits, tracked changes, or visual/structural revisions (often paired with `<ins>`).	Outdated information, deprecation notices, old prices, or sold-out items.
Accessible Code Pattern	`The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.`	`The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.`	`<span class="sr-only">Original price: </span><s>$100.00</s>`
Visible Representation	The meeting is on ~~Monday~~ Wednesday	The meeting is on ~~Monday~~ Wednesday	~~$100.00~~ $34.99
Unique Attributes	`cite` (URL pointing to the explanation of the deletion) `datetime` (date/time of the deletion)	`cite` (URL pointing to the explanation of the deletion) `datetime` (date/time of the deletion)	None
Default Browser Style	By default, it has an underline but it can be changed to a bold style, put a background green to show insertion, etc.	Renders with a visual line-through (strikethrough)	Renders with a visual line-through (strikethrough)

Implicit ARIA Mapping: role="deletion" and role="insertion"

The <del> and <s> tags map to the accessibility role of deletion (and <ins> to insertion). Sighted users see these as struck through or underlined, but screen reader support for announcing these changes is inconsistent.

Understanding the Accessibility Tree Mapping

Under the W3C Accessibility API Mappings, these tags are programmatically mapped to specific accessibility roles that browsers expose to the OS accessibility tree:

<del> maps to role="deletion" (see HTML-AAM <del> mapping and Core-AAM deletion role map).
<s> maps to role="deletion" (see HTML-AAM <s> mapping and Core-AAM deletion role map).
<ins> maps to role="insertion" (see HTML-AAM <ins> mapping and Core-AAM insertion role map).

These mappings instruct the browser's accessibility engine on how to expose the semantics to assistive technology. However, screen reader support is inconsistent:

Natively Announced:
- VoiceOver + Safari (iOS)
- NVDA + Firefox
- TalkBack + Chrome
Not Announced:
- NVDA + Chrome
- TalkBack + Firefox
- VoiceOver + Safari (macOS)

How we provide context for combinations without native support on the Accessibility Tree

To make up for the lack of support, we should add a visually hidden text (e.g., using a .sr-only class) to provide more context about what is happening with the information.

The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.

By framing the visually hidden text as natural contextual descriptors (e.g., "previous date:" and "new date:"), the output will be more coherent and meaningful across all assistive technologies. It is recommended to avoid redundant labels like "deletion" and "insertion".

On unsupported systems: Announces "previous date: Monday, new date: Wednesday". The semantic change is fully communicated through the descriptive context.
On supported systems: Announces "previous date: deletion, Monday, new date: insertion, Wednesday". This reads as a coherent, descriptive sentence without redundant verbal stuttering.

CSS Styling Tips

You can customize the visual representation of <del>, <s>, and <ins> tags to match your design system using standard CSS text-decoration properties, as well as define a utility class to hide screen-reader context labels.

Customizing `<del>` and `<s>`

To style deletions and strikethroughs:

/* Customize individually */
s, del {
  text-decoration-line: line-through;
  text-decoration-color: #e06c75;     /* Change line color */
  text-decoration-style: wavy;     /* double, dashed, wavy, solid */
  text-decoration-thickness: 1.5px;   /* Change line thickness */
}

/* Or use the shorthand syntax */
s, del {
  text-decoration: line-through #e06c75 wavy 1.5px;
}

Customizing `<ins>`

To style insertions:

/* Customize individually */
ins {
  text-decoration-line: underline;
  text-decoration-color: #98c379;     /* Change line color */
  text-decoration-style: wavy;  /* double, dashed, wavy, solid */
  text-decoration-thickness: 1.5px;   /* Change line thickness */
}

/* Customize addition of code */
ins {
  white-space: pre;
  text-decoration: none;
  background: #3fb950;
}

/* Or use the shorthand syntax */
ins {
  text-decoration: underline #98c379 wavy 1.5px;
}

Visual Hiding Utility

To hide descriptive contextual labels (like "previous date:") from visual users while keeping them accessible to screen readers, implement a standard visually-hidden CSS class:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

Resources and Documentation

Clarification on MDN's Pseudo-Element Solution:
MDN suggests using CSS generated content (::before / ::after) to announce which text was deleted and which text was inserted. However, I opted for another also valid solution. According to my tests, using visually hidden DOM nodes is much more reliable and stable to ensure a clear context.

Master price tags

Mica — Mon, 17 Aug 2026 20:02:48 +0000

Understanding when to use `<ins>`, `<del>` and `<s>` HTML tags

Comparative Feature	`<ins>` element	`<del>` element	`<s>` element
Semantic Definition	Represents the content that has been added to a document.	Represents a range of text that has been deleted from a document.	Represents content that is no longer accurate, correct, or relevant.
Use Case	New edits in a code, in a text, tracked changes	Document edits, tracked changes, or visual/structural revisions (often paired with `<ins>`).	Outdated information, deprecation notices, old prices, or sold-out items.
Accessible Code Pattern	`The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.`	`The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.`	`<span class="sr-only">Original price: </span><s>$100.00</s>`
Visible Representation	The meeting is on ~~Monday~~ Wednesday	The meeting is on ~~Monday~~ Wednesday	~~$100.00~~ $34.99
Unique Attributes	`cite` (URL pointing to the explanation of the deletion) `datetime` (date/time of the deletion)	`cite` (URL pointing to the explanation of the deletion) `datetime` (date/time of the deletion)	None
Default Browser Style	By default, it has an underline but it can be changed to a bold style, put a background green to show insertion, etc.	Renders with a visual line-through (strikethrough)	Renders with a visual line-through (strikethrough)

Implicit ARIA Mapping: role="deletion" and role="insertion"

Understanding the Accessibility Tree Mapping

Under the W3C Accessibility API Mappings, these tags are programmatically mapped to specific accessibility roles that browsers expose to the OS accessibility tree:

<del> maps to role="deletion" (see HTML-AAM <del> mapping and Core-AAM deletion role map).
<s> maps to role="deletion" (see HTML-AAM <s> mapping and Core-AAM deletion role map).
<ins> maps to role="insertion" (see HTML-AAM <ins> mapping and Core-AAM insertion role map).

These mappings instruct the browser's accessibility engine on how to expose the semantics to assistive technology. However, screen reader support is inconsistent:

Natively Announced:
- VoiceOver + Safari (iOS)
- NVDA + Firefox
- TalkBack + Chrome
Not Announced:
- NVDA + Chrome
- TalkBack + Firefox
- VoiceOver + Safari (macOS)

How we provide context for combinations without native support on the Accessibility Tree

To make up for the lack of support, we should add a visually hidden text (e.g., using a .sr-only class) to provide more context about what is happening with the information.

The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.

On unsupported systems: Announces "previous date: Monday, new date: Wednesday". The semantic change is fully communicated through the descriptive context.
On supported systems: Announces "previous date: deletion, Monday, new date: insertion, Wednesday". This reads as a coherent, descriptive sentence without redundant verbal stuttering.

CSS Styling Tips

Customizing `<del>` and `<s>`

To style deletions and strikethroughs:

/* Customize individually */
s, del {
  text-decoration-line: line-through;
  text-decoration-color: #e06c75;     /* Change line color */
  text-decoration-style: wavy;     /* double, dashed, wavy, solid */
  text-decoration-thickness: 1.5px;   /* Change line thickness */
}

/* Or use the shorthand syntax */
s, del {
  text-decoration: line-through #e06c75 wavy 1.5px;
}

Customizing `<ins>`

To style insertions:

/* Customize individually */
ins {
  text-decoration-line: underline;
  text-decoration-color: #98c379;     /* Change line color */
  text-decoration-style: wavy;  /* double, dashed, wavy, solid */
  text-decoration-thickness: 1.5px;   /* Change line thickness */
}

/* Customize addition of code */
ins {
  white-space: pre;
  text-decoration: none;
  background: #3fb950;
}

/* Or use the shorthand syntax */
ins {
  text-decoration: underline #98c379 wavy 1.5px;
}

Visual Hiding Utility

To hide descriptive contextual labels (like "previous date:") from visual users while keeping them accessible to screen readers, implement a standard visually-hidden CSS class:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

Resources and Documentation

Clarification on MDN's Pseudo-Element Solution:
MDN suggests using CSS generated content (::before / ::after) to announce which text was deleted and which text was inserted. However, I opted for another also valid solution. According to my tests, using visually hidden DOM nodes is much more reliable and stable to ensure a clear context.

Learn how to build a disclosure component using the native HTML details tag

Mica — Mon, 17 Aug 2026 13:08:06 +0000

Welcome to a new entry in my section dedicated to creating reusable and, above all, accessible components. This time, we are going to learn how to use the HTML <details> tag to create a disclosure component without the need for JavaScript or WAI-ARIA.

Requirements to have a functional disclosure

To make a disclosure accessible, a few requirements must be met:

When the focus is on the disclosure element header <summary>, it must be possible to collapse and expand it by pressing the Enter or Space keys.
When pressing Tab, the focus moves to the next interactive element inside the disclosure element or, if there are none, to the next interactive element on the page.
When pressing Shift + Tab, the focus moves to the previous interactive element.
The screen reader must announce the state of the element, that is, whether it is collapsed or expanded. It must also announce its accessible name.

The <details> tag will help us meet all these points, since it is natively accessible.

Anatomy of the details tag

: The main element that wraps the whole disclosure element.
: First direct child of the <details> tag. It is used as a header acting as the control to expand or collapse the content. There is no need to group the content of the summary inside another tag, but the following tags are valid to use: <h1>-<h6> and phrasing content.
::marker: The disclosure triangle that indicates whether the element is open or closed.
::details-content: Direct child of the <details> tag and sibling of <summary> and it can be any valid HTML element. The best part is that there is no need to wrap the content inside a div or a fragment, natively the <details> tag will detect it as a content.

Attributes

open: This attribute indicates whether the details content is expanded or collapsed.
- This attribute is implicit on the tag, so there is no need to add it because the details tag is collapsed by default.
- If a plain open is added, the details will be expanded by default.
name: This attribute will only be necessary when it is needed to manage more than one details element as a group. In other words, if one details is open and another is opened, the previously open one will automatically close.

CSS Strategies to Style The Disclosure Component

How to style summary

Natively, the <summary> tag comes by default with the property display: list-item. This property gives us the native the disclosure icon, which can be a triangle, a circle, only the disclosure-open or the disclosure-close icon, or use the CSS at-rule @counter-style to set a predefined list of icon styles. On the other hand, with the pseudo-element ::marker, the disclosure icon can be styled:

::marker – Code Snippet

::marker {
  color: orangered;
  font-size: 2rem;
}

::marker – Functional Example

Cool, but now, how can the native disclosure icon be omitted? Since the <summary> tag comes by default with the property display: list-item, by simply adding a display: flex on the details > summary selector, the native disclosure icon is hidden automatically. This strategy is valid, but it is necessary to have a visual symbol that makes it explicit that this is a disclosure element. The added icon should be aria-hidden="true" because assistive technology users will already perceive the role and the state of the element.

Removing Native Disclosure Icon – Code Snippet

details > summary {
  display: flex;
  flex-direction: row;
  align-items: center;
  justify-content: space-between;
}

Removing Native Disclosure Icon – Functional Example

Finally, I would like to comment that there is also another well-known pseudo-element named ::-webkit-details-marker that is used in WebKit-based browsers to style details marker. To be honest, that pseudo-selector today is not really necessary since ::marker is well supported across different browsers.

Bye, bye div to generate content!

Since September 2025, we have the CSS pseudo-selector ::details-content that auto-generates a wrapper box to style the expandable/collapsible content of the <details> tag. This is good news because now we do not need to rely on a non-semantic tag, like a div, to style the wrapper of the content and to handle the transitions from the collapsed state to the expanded and vice versa.

Expandable/Collapsible Content – CSS Snippet

details::details-content {
  block-size: 0;
  overflow: clip;
}

details[open]::details-content {
  padding: 0.85rem;
}

@media (prefers-reduced-motion: no-preference) {
  details::details-content {
    transition:
      block-size 0.3s ease,
      padding-block 0.3s ease,
      content-visibility 0.3s ease allow-discrete;
  }
}

details::details-content, holds the styles for the collapsed default state and hides the content.
details[open]::details-content, holds the styles for the expanded state. It will determine the end of the animation, if there is any.
@media (prefers-reduced-motion: no-preference) {details::details-content {}}, this is an accessibility improvement! Here is where the animation between the closed and open states is going to live if the user has animations enabled in their operating system.

Expandable/Collapsible Content – Functional Example

A correct semantic structure would be rendered as the following block of code, and you will not find any non-semantic HTML element:

<details>
  <summary>{...}</summary>
  {here starts the ::details-content}
  <p>{...}</p>
  <h4>{...}</h4>
  <ul>
    <li>{...}</li>
    <li>{...}</li>
    <li>{...}</li>
  </ul>
</details>

Keyboard Navigation

The element that receives focus and manages the interaction is summary

Key	Action
Tab	Move focus to the disclosure element or move focus to the next disclosure element
Shift + Tab	Move focus to the previous disclosure element or move focus to the previous interactive element
Space or Enter	Expands/collapses the details element

Screen Readers

Here is how different combinations of browsers, devices and screen readers announce and interact with a disclosure element:

VoiceOver macOS Tahoe 26.5.2 + Safari 26.5.2 (21624.2.5.11.8):
- Collapsed: 'How do screen readers announce the details tag?, collapsed, summary'
- Expanded: 'How do screen readers announce the details tag?, expanded, summary'
- Toggle state with keys combination Control + Option + Space: 'collapsed' or 'expanded'
VoiceOver macOS Tahoe 26.5.2 + Chrome 150.0.7871.184:
- Collapsed: 'How do screen readers announce the details tag?, collapsed, disclosure triangle, group'
- Expanded: 'How do screen readers announce the details tag?, expanded, disclosure triangle, group'
- Toggle state with keys combination Control + Option + Space: if it is collapsed, the whole thing again is announced as collapsed and if it is expanded, the whole thing again is announced as expanded
VoiceOver macOS Tahoe 26.5.2 + Firefox 152.0.6:
- same as in the combination VoiceOver macOS Tahoe 26.5.2 + Chrome 150.0.7871.184
NVDA 2026.1.1 + Chrome 150.0.7871.18:
- Collapsed: 'How do screen readers announce the details tag?, button, collapsed'
- Expanded: 'How do screen readers announce the details tag?, button, expanded'
- Toggle state with Enter or Space: 'collapsed' or 'expanded'
NVDA 2026.1.1 + Firefox 153.0:
- Collapsed: 'How do screen readers announce the details tag?, button, collapsed'
- Expanded: 'How do screen readers announce the details tag?, button, expanded'
- Toggle state with Enter or Space: 'collapsed' or 'expanded'
TalkBack, Pixel 10, Android 16 + Chrome 149.0.7827.160:
- Collapsed: 'collapsed, How do screen readers announce the details tag?, disclosure triangle'
- Expanded: 'expanded, How do screen readers announce the details tag?, disclosure triangle'
- Toggle state by double-tapping to activate: 'collapsed' or 'expanded'
TalkBack, Pixel 10, Android 16 + Firefox 145.0.2:
- Collapsed: 'collapsed, How do screen readers announce the details tag?, button, How do screen readers announce the details tag?, Space'
- Expanded: 'expanded, How do screen readers announce the details tag?, button, How do screen readers announce the details tag?, Space'
- Toggle state by double-tapping to activate: 'collapsed' or 'expanded'

Use cases

The same element powers very different UI. Here are a few patterns built with nothing but its native tags, the name attribute and the ::details-content pseudo-element, still with zero JavaScript.

FAQ section: One answer open at a time. The same name attribute on every panel makes the browser close the others for you.
Inline "read more": Keep the intro, hide the detail. display: inline on the details and ::details-content folds it into the sentence.
Spoiler or show solution: Hide an answer, a code solution, or a plot spoiler behind an explicit reveal. Closed, the content stays out of view and out of the accessibility tree.
Show order details: Keep a card design that has the specifics behind a toggle. Perfect for order metadata, technical specs, or anything power-users want but everyone else can skip.
Animated markers: Because the open/close state is a plain CSS selector, you can animate any marker you like: a chevron that spins, a dot that turns into a ring.
Collapsible filter panel: Group form controls under collapsible headers to keep a long filter rail scannable. Each group remembers its own state; the inputs inside work exactly as they would anywhere else.
Specifications: Keep the buy box clean and file the full spec sheet behind a toggle. Shoppers who need dimensions, materials, or care instructions open it.
Collapsed code and logs: The GitHub pattern: fold a long code sample, diff, or stack trace behind a summary so issues and docs stay scannable. The revealed block is a monospace panel. . This use case uses the tag <ins> for the insertion of the new lines. You can read more about this tag its use here

Thanks for reading and leave your comments :)

What is going on?

Mica — Sun, 12 Jul 2026 20:01:35 +0000

Playing the game of writing technical post was funny two years ago. Now, I am a mod and it is incredible the amount of posts generated by AI that I have to review. Personally, I enjoy reading posts written by humans because it is fun to discover their tone and style, it is fun to read the titles, it is fun to read their experience without having to deal with "it is not A, it is B". JUST STOP. If you do not have anything to share, do not share ANYTHING. We do not need quantity, we need quality.
I want messy posts. I want to know that behind the screen there is a human investing their time typing as in the old days. It does not matter if English is not your first language, just write, just read, just share and be wrong. By making mistakes, you learn.
Finally, I want to share my concerns about the accessibility web community because it worries me how pages like dev.to, smashing magazine, reddit etc, etc have become a sea of ai-generated "accessible" libraries or software to detect automated issues. What is going on? The situation is insufferable.

Where the humans that generate accessibility content gather today? I do not want to engage with bots anymore.

How to write an accessible price tag for e-commerces

Mica — Fri, 26 Jun 2026 06:29:10 +0000

Understanding when to use `<del>` and `<s>` HTML tags

Comparative Feature	`<del>` element	`<s>` element
Semantic Definition	Represents a range of text that has been deleted from a document.	Represents content that is no longer accurate, correct, or relevant.
Use Case	Document edits, tracked changes, or visual/structural revisions (often paired with `<ins>`).	Outdated information, deprecation notices, old prices, or sold-out items.
Accessible Code Pattern	`The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.`	`<span class="sr-only">Original price: </span><s>$100.00</s>`
Visible Representation	The meeting is on ~~Monday~~ Wednesday	~~$100.00~~ $34.99
Unique Attributes	`cite` (URL pointing to the explanation of the deletion) `datetime` (date/time of the deletion)	None
Default Browser Style	Renders with a visual line-through (strikethrough)	Renders with a visual line-through (strikethrough)

Implicit ARIA Mapping: role="deletion" and role="insertion"

Understanding the Accessibility Tree Mapping

Under the W3C Accessibility API Mappings, these tags are programmatically mapped to specific accessibility roles that browsers expose to the OS accessibility tree:

<del> maps to role="deletion" (see HTML-AAM <del> mapping and Core-AAM deletion role map).
<s> maps to role="deletion" (see HTML-AAM <s> mapping and Core-AAM deletion role map).
<ins> maps to role="insertion" (see HTML-AAM <ins> mapping and Core-AAM insertion role map).

These mappings instruct the browser's accessibility engine on how to expose the semantics to assistive technology. However, screen reader support is inconsistent:

Natively Announced:
- VoiceOver + Safari (iOS)
- NVDA + Firefox
- TalkBack + Chrome
Not Announced:
- NVDA + Chrome
- TalkBack + Firefox
- VoiceOver + Safari (macOS)

How we provide context for combinations without native support on the Accessibility Tree

To make up for the lack of support, we should add a visually hidden text (e.g., using a .sr-only class) to provide more context about what is happening with the information.

The meeting is on <span class="sr-only">previous date: </span><del>Monday</del> <span class="sr-only">new date: </span><ins>Wednesday</ins>.

On unsupported systems: Announces "previous date: Monday, new date: Wednesday". The semantic change is fully communicated through the descriptive context.
On supported systems: Announces "previous date: deletion, Monday, new date: insertion, Wednesday". This reads as a coherent, descriptive sentence without redundant verbal stuttering.

CSS Styling Tips

Customizing `<del>` and `<s>`

To style deletions and strikethroughs:

  /* Customize individually */
  s, del {
    text-decoration-line: line-through;
    text-decoration-color: #e06c75;     /* Change line color */
    text-decoration-style: wavy;       /* double, dashed, wavy, solid */
    text-decoration-thickness: 1.5px;   /* Change line thickness */
  }

  /* Or use the shorthand syntax */
  s, del {
    text-decoration: line-through #e06c75 wavy 1.5px;
  }

Customizing `<ins>`

To style insertions:

  /* Customize individually */
  ins {
    text-decoration-line: underline;
    text-decoration-color: #98c379;     /* Change line color */
    text-decoration-style: wavy;       /* double, dashed, wavy, solid */
    text-decoration-thickness: 1.5px;   /* Change line thickness */
  }

  /* Or use the shorthand syntax */
  ins {
    text-decoration: underline #98c379 wavy 1.5px;
  }

Visual Hiding Utility

To hide descriptive contextual labels (like "previous date:") from visual users while keeping them accessible to screen readers, implement a standard visually-hidden CSS class:

  .sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    clip-path: inset(50%);
    white-space: nowrap;
    border: 0;
  }

Resources and Documentation

Disclaimer on MDN's Pseudo-Element Solution:
Clarification on MDN's Pseudo-Element Solution: MDN suggests using CSS generated content (::before / ::after) to announce which text was deleted and which text was inserted. However, I opted for another also valid solution. According to my tests, using visually hidden DOM nodes is much more reliable and stable to ensure a clear context.

Link or Button, that is the question.

Mica — Mon, 22 Jun 2026 12:41:07 +0000

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 button.

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 reset all the values of an input or inputs to its initial value.

<button type=”button” onclick="openModal()">
  Open Modal
</button>

Keyboard Interaction

It can only be activated by pressing the keys Enter or Space.

Screen Readers Interaction

Screen Readers, generally, announce buttons in the following way: "Button, [Accessible Name of the button]". 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 link by doing the following:

<button onclick="window.location.href='/'">
  Go to homepage
</button>

If you need to do this, it means that you need a link.

Which one should I use: link or button?

Do you need an expandable section? use a <button> with the state aria-expanded and the focus should stay put.
Do you need to jump to a section on the same page? use an <a href="#section">. There is no page load, updated the url, lands the user at a destination.
Do you need to load more items into the current list? use a <button> and when the items load, the focus should be placed in the first item of the new items.
Do you need to redirect the user to a new location to read more about something? use an <a href="/destination">.
Do you need to open a menu? use a <button> with the states aria-haspopup and aria-expanded.
Do you need to play or pause a video? use a <button>.
Do you need to dowload a file? use a <a> with the attribute download.
Do you need a card that leads to a detail page? use a <a> stretched ::after.

Focus Style for Interactive Elements

It is vital for keyboard and screen reader users to have a visual and logic focus on interactive elements. Never do outline: none without providing a focus style:

a:focus-visible,
button:focus-visible {
  outline: 4px solid #0066ff;
  outline-offset: 4px;
}

Enlace o botón, esa es la cuestión

Mica — Mon, 22 Jun 2026 12:33:01 +0000

¿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ón que vaya a llevar a cabo.
- type="button": se utiliza si el botón no tiene un comportamiento determinado.
- type="submit": se utiliza si el botón envía información a un servidor.
- type="reset": se utiliza para resetear todos los inputs de un formulario a su valor inicial.

<button type=”button” onclick="openModal()">
  Abrir modal
</button>

Interacción con el teclado

Solo se puede activar con la teclas Enter o Space.

Interacción con lectores de pantalla

Los lectores de pantalla, generalmente, anuncian el elemento de la siguiente manera: "Botón, [nombre accessible del botón]" por lo cual es importante que el botón tenga un nombre accesible pertinente y descriptivo.

Mala práctica

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:

<button onclick="window.location.href='/'">
  Ir a página de inicio
</button>

Si necesitas hacerlo, quiere decir que necesitas un enlace

¿Enlace o botón? ¿Cuál debo usar según mi necesidad?

¿Necesitas expandir una sección? Usá un <button> con el estado aria-expanded y el foco debe mantenerse en el botón.
¿Necesitas saltar a una sección dentro de la misma página? Usa un <a href="#section">. No tiene que haber una actualización de la página, se modifica el URL con la nueva referencia ID y se redirige al usuario a la nueva ubicación.
¿Necesitas cargar más ítems en una lista? Usa un <button> y cuando los nuevos ítems se carguen, el foco se debe ubicar en el primer nuevo ítem.
¿Necesitas redirigir al usuario a una nueva ubicación para que lea más sobre algo? Usa un <a href="/destination">.
¿Necesitas abrir un menú? Usa un <button> con los estados aria-haspopup y aria-expanded.
¿Necesitas reproducir o pausar un vídeo? Usa un <button>.
¿Necesitas descargar un archivo? Usa un <a> con el atributo download.
¿Necesitas que una sección lleve al usuario a la página de detalles? Usa un <a> estirado con un ::after.

Estilo del foco para elementos interactivos

Para los usuarios de teclado y lectores de pantalla es vital que los elementos interactivos tengan una un foco visual y lógico. Nunca hagas outline: none sin antes estilar el foco:

a:focus-visible,
button:focus-visible {
  outline: 4px solid #0066ff;
  outline-offset: 4px;
}

Accessible and Functional Quantity Spinbutton Pattern

Mica — Wed, 13 May 2026 10:35:07 +0000

Introduction

Disclaimer: This is not a written-in-stone guide, I can make mistakes, so please let me know if you disagree with something.

Expected behaviors

Keyboard

Key	Action
Up Arrow	Increases the value by its step value
Down Arrow	Decreases the value by its step value
Home	If the spinbutton has a minimum value, sets the value to its minimum
End	If the spinbutton has a maximum value, sets the value to its maximum
Command or Fn + Right Arrow	Substitute for Apple's keyboards that do not have a End key to set the value to its maximum
Command or Fn + Left Arrow	Substitute for Apple's keyboards that do not have a End key to set the value to its minimum

Screen Readers

NVDA Navigation

Browse Mode: Browse mode is used when reading documents or web pages.
Focus Mode: Focus mode is used when the user enters a form or other fields that require user input.

NVDA automatically switches between Browse and Focus modes, but the user can toggle them using Insert + Space Bar.
| Command | Task |
|--------|-----|
| Down Arrow (Browse Mode) | Read next item |
| Enter or Space Bar | Activate button |
| Down Arrow (Focus Mode) | Decrement by step |
| Up Arrow (Focus Mode) | Increment by step |
| Home | Jump to aria-valuemin (via your custom handler) |
| End | Jump to aria-valuemax (via your custom handler) |
| Tab | Commit value, leave the field, return to browse mode |

VoiceOver Navigation

Command	Task
Tab/Shift + Tab	Go to next/previous focusable item (link, button, input, etc.)
VO + Space Bar	Activate a link or form control
VO + Right Arrow	Move VO cursor to next element (not limited to focusable items)
VO + Left Arrow	Move VO cursor to previous element
VO + Shift + Down Arrow	Once the VO cursor is on the spinbutton, this combination enters the spinbutton
Up Arrow	Once inside the spinbutton, increment by step
Down Arrow	Once inside the spinbutton, decrement by step
Home	Jump to aria-valuemin (via your custom handler)
End	Jump to aria-valuemax (via your custom handler)

Gestures VoiceOver - iOS

Gesture	Task
Swipe next	Read next item
Swipe left	Read previous item
Double-tap	Activate (link, button)
Swipe up	If the VO cursor is over the spinbutton, increase the value
Swipe down	If the VO cursor is over the spinbutton, decrease the value

Gestures Talkback - Android

Gesture	Task
Swipe next	Read next item
Swipe left	Read previous item
Double-tap	Activate (link, button)
Swipe up	If the VO cursor is over the spinbutton, increase the value
Swipe down	If the VO cursor is over the spinbutton, decrease the value

Pattern A: APG (ARIA Authoring Practices Guide) Spinbutton by W3C

The code in this example is not intended for production environments. Before using it for any purpose, read this to understand why.

and then a list of reasons why you should be critical of the pattern provided. In this case, the most important one is:

Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heeding the warning that No ARIA is better than Bad ARIA.

So, what does this mean? Well, a couple of important things:

Always be critical of everything (a rule for life, tho)
Keep in mind the necessities and limitations of your product/business, and (more importantly) comply with the regulations and legislation in order to guarantee freedom of navigation through your product for users with disabilities.
There is always (well, almost 80% always) an HTML equivalent.

The 2026 WebAIM Million analysis found notable increases in both the number of detected accessibility errors and number of pages with WCAG conformance failures, reversing a trend of gradual accessibility improvements in recent years. A primary concern is the significant increase in home page complexity and ARIA code, both of which correlate to increased detectable errors. These trends likely reflect broader shifts in web development including increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices (“vibe coding”). Home pages are getting larger and more technologically complex at an alarming rate, making accessibility more difficult to achieve and maintain. A key takeaway from this year's report is improving accessibility at scale will require both better practices and simpler systems. Alternatively, complex systems need to do a better job of focusing on accessibility fundamentals.

Functional Example – APG

you can find the functional example here

APG code

<input 
  id="add-to-bag"
  role="spinbutton"
  type="text"
  inputMode="numeric"
  pattern="[0-9]*"
  autoComplete="off"
  spellCheck="false"
  aria-valuemin={MIN}
  aria-valuemax={MAX}
  aria-valuenow={isValid ? numeric : undefined}
  aria-valuetext={value}
  aria-invalid={!isValid || undefined}
  aria-describedby={isValid ? 'help-add-to-bag' : 'help-add-to-bag error-add-to-bag'}
  value={value}
  onChange={handleChange}
  onKeyDown={handleKeyDown}
/>

id: to relate the <input /> with the <label> element
role="spinbutton": this is a WAI-ARIA role that allows the user to increase and decrease a value within a given range. This role can be used on <input> or on a non-semantic element such as <div>. The APG pattern for the spinbutton component proposes the <input> with a type="text" making the development more challenging. The expected keyboard behavior for a spinbutton is being able to increment or decrement the value by pressing the up/down arrow accordingly. Since this is not a native interaction of the role="spinbutton" or of the <input type="text" />, we have to programmatically cover these behaviors. The spinbutton element with type text generally comes with two buttons (one for decrement and the other to increment the value) that should be excluded from the navigation flow by adding tabIndex={-1}.
type="text": implies that the spinbutton will receive a value of type text, which is a pain because it means that we have to transform the type text to type number later.
inputMode="numeric": since the input is type text, we have to make the browsers know which virtual keyboard they will have to display. This is vital for mobile navigation because without the value numeric the virtual keyboard display to enter a value will be a QWERTY instead of a numeric input keyboard.
pattern="[0-9]*": again, since the input is type="text", we have to use a regex to only admit values of type number. (This attribute was not on the APG example, but I cannot help myself).
autocomplete="off": it is used on inputs that take a text or numeric value as input to prevent the browser from automatically entering a value into this field. (again, my take, not on APG example).
aria-valuemin="[NUMBER]": sets the minimum value allowed for the spinbutton. The default is 0, if no value is passed.
aria-valuemax="[NUMBER]": sets the maximum value allowed for the spinbutton. The default is 100, if no value is passed.
aria-valuenow="[number]": here things start to get interesting. By definition, this attribute defines the current value for a range widget (meter, scrollbar, slider and spinbutton). Since we are not using a semantic solution, this value should be updated programmatically. Also, this value is intended for numeric values and APG provides an example where the spinbutton is being considered as a text, so we have to also transform the value from type string to type number. This is not everything! Since the spinbutton is not correctly typed, the announcement of the current value will be done as a percent by VoiceOver (macOS and iOS) announces it as a percent, TalkBack on Pixel 10 does not announce it at all, and NVDA announces it correctly. You can test it on the APG example.
aria-invalid="[boolean]": indicates that the current value is invalid.
aria-describedby="[IDREF]": this attribute is used to establish a relationship between widgets or groups and the text that describes them.

Conclusion for the APG Spinbutton Pattern

Pattern B: Native HTML solution

Blink: this is the browser engine for Chrome, Edge, Opera and Brave (all browsers based on Chromium) which means all the browsers are going to have the same Accessibility Tree as the one we can see on the following image:

Supported on the following Accessibility APIs:

Windows: IAccessible, IAccessible2 and UIAutomation
Mac: NSAccessibility (funny thing here is that Blink creates a more accurate and complete node than WebKit and VoiceOver announces the spinbutton better on Chrome, as we are going to read later)
Linux: ATK
Android: AccessibilityNodeInfo and AccessibilityNodeProvider. I opened a ticket for this operating system because it is not exposing the spinbutton correctly preventing the user from having an accessible experience. The ticket to Android can be seen here
- Gecko: this is the browser engine for Firefox. The Accessibility Tree it creates, in my opinion, is the most complete and it is compatible with the following Accessibility APIs:
Windows: IAccessible, IAccessible2 and UIAutomation
Mac: mozAccessible
Linux: ATK
- WebKit: this is the browser engine for Safari in macOS and iOS. Here is where our problems start. The engine does not recognize the element as a spinbutton but as a role="textbox" if we don't explicitly pass the role="spinbutton" to the <input type="text" />. This is an issue because the VoiceOver screen reader in both devices, desktop and mobile, will prevent the user from having an accessible experience, the same issue that I faced on Android. Again, I ended up opening a ticket to Apple about this behavior. The ticket to Apple can be seen here

Functional Example – HTML

The native functional example can be found here

HTML native code

<input 
  id="add-to-bag-native"
  type="number"
  role="spinbutton"
  autoComplete="off"
  min={MIN}
  max={MAX}
  step={STEP}
  value={value}
/>

id: same thing as in the APG pattern
type="number": this is what natively converts an input into a spinbutton and restricts it to numeric values. It natively supports supports increasing and decreasing the value by: pressing the native controls that come with the input type="number" (see/read/perceive the image below), pressing Up Arrow or Down Arrow, or swiping (on mobile with the screen readers on).

  input[type="number"] {
    appearance: textfield;
  }

  input[type="number"]::-webkit-outer-spin-button,
  input[type="number"]::-webkit-inner-spin-button {
    -webkit-appearance: none;
    margin: 0;
  }

appearance: textfield;, we need it to strip the native spinbutton styling in Firefox
::-webkit-outer-spin-button and ::-webkit-inner-spin-button are pseudo-selectors that only Blink and WebKit recognize and the -webkit-appearance: none property strips the native spinbutton styling in Chrome and Safari.
- role="spinbutton": well, having in mind all the compatibility issues we have in different browsers, I found out that if you only pass the WAI-ARIA role="spinbutton" magically they all disappear. So, there is no harm in adding it to prevent headaches in the future. This post was built for this moment, you can thank me.
- autoComplete="off": just the same as in the APG example
- min={NUMBER}: the minimum value to accept for this input and should be less than or equal to the maximum value. If a value that isn't a valid number is specified, then the input has no minimum.
- max={NUMBER}: the maximum value to accept for this input and should be greater than or equal to the minimum value.
- step={NUMBER}: defines the allowed interval between valid values. The default is 1 and only accepts integers.
- value={NUMBER}: a number representing the value of the number entered into the input

Conclusion for the HTML native solution

Chrome (version 148) + macOS (Tahoe version 26.4.1) + VoiceOver
Chrome (version 148) + iOS (version 26.4.1)/ iPhone pro 15 + VoiceOver
Chrome (version 148) + Windows 11 + NVDA
Chrome (version 148) + Android/Pixel 10 (version 16) + TalkBack
Firefox (version 150) + Windows 11 + NVDA
Firefox (version 150) + macOS (Tahoe version 26.4.1)
Safari (version 26.4) + macOS (Tahoe version 26.4.1) + VoiceOver
Safari (version 26.4) + iOS (version 26.4.1) + VoiceOver

  const handleKeyDown = (ev: KeyboardEvent<HTMLInputElement>) => {
    if (ev.key === 'End' || (ev.metaKey && ev.key === 'ArrowRight')) {
      ev.preventDefault()
      setValue(MAX)
    } else if (ev.key === 'Home' || (ev.metaKey && ev.key === 'ArrowLeft')) {
      ev.preventDefault()
      setValue(MIN)
    }
  }

Final Thoughts

You can find me on:

email: micaela.avigliano@gmail.com
linkedin: https://www.linkedin.com/in/micaelaavigliano/

Accessible Pretext demo

Mica — Tue, 31 Mar 2026 13:07:24 +0000

What I did

I took the demo for a editorial engine built with pretext by Cheng Lou and I made it fully accessible, with semantic HTML structure, keyboard operability, screen reader support, and prefers-reduced-motion compliance. The result is a high-performance text layout demo that meets WCAG 2.2 success criteria while not compromising aesthetics and performance. The orbs are still draggable with the mouse but I also added the possibility of moving them using the keyboard.

The app uses a dual rendering system. At normal zoom, pretext powers a visual stage where text lines are individually positioned and wrap dynamically around the orbs as circular obstacles. Underneath, a native HTML <article> with CSS column-count remains in the DOM for screen readers, copy/paste, and find-in-page. At high zoom (≥150%) or narrow viewports (<500px), the pretext stage is removed entirely and the native HTML article becomes the visible layout, ensuring text is always fully readable, selectable, and copyable. A pretext-rendered drop cap provides the decorative initial letter in the visual stage, while CSS ::first-letter handles it in the native fallback.

Pretext library usage

Pretext powers the orb animation system. The following APIs are available in the project:

API	Purpose	Where used
`prepareWithSegments()`	Measures and caches word widths for text blocks	Body text preparation on font load
`layoutNextLine()`	Lays out one line of text at a given max width	Core layout loop — wraps text around orb obstacles
`layoutWithLines()`	Lays out all lines of a prepared text block	Headline fitting to available width/height
`walkLineRanges()`	Iterates line ranges without allocating line objects	Text measurement utilities

Accessibility improvements

Semantic HTML structure

The app uses proper HTML5 landmarks and semantic elements:

<header>: Fixed bar with controls and interaction hints
<main>: Primary content area
<article lang="es">: Full readable text as native HTML; lang="es" switches screen readers to Spanish pronunciation
<section>: Orb container with descriptive aria-label, exposed as a named region
<footer>: Performance stats and credits
<kbd>: Keyboard shortcuts styled as keycaps. aria-hidden prevents SR double-announcement; sr-only siblings provide the readable text
<cite>: Book title attribution
<nav>: Keyboard shortcuts and credits navigation

Keyboard accessibility

Every interactive element is operable without a mouse:

Action	Key	With VoiceOver
Toggle global pause	`Esc`	`Esc`
Navigate to orbs	`Tab`	`Tab`
Move focused orb	`Arrow keys`	`Option + Arrow keys`
Pause/resume individual orb	`Space`	`Space`

Orbs are native <button> elements. aria-roledescription="draggable orb" augments the role announcement so the user understands these are not ordinary buttons. Each orb's aria-label is dynamic and encodes its position in the set, the available interactions, and its current pause state.

Screen reader orb interaction discovery

When a VoiceOver user tabs to an orb, they hear: "Golden orb, 1 of 5. Use Option plus arrow keys to move. Press Space to pause." The instruction lives inside the aria-label because VoiceOver captures plain arrow keys for its own navigation; the page tells the user which key combination it can receive (Option + Arrow) instead of attempting to override the screen reader. When the orb is paused, the label changes to "Press Space to resume."

Screen reader support

aria-live="polite": Announces orb selection, pause/resume, and state changes without interrupting the user
aria-pressed: Toggle buttons communicate their on/off state
aria-label: Every interactive element has a descriptive, dynamic label

`prefers-reduced-motion` support

When the user's OS or browser has reduced motion enabled:

All orb animation stops, orbs render at their initial positions, static
CSS scroll-snap-type and scroll-behavior: smooth are disabled
CSS transitions and animations are suppressed globally via animation-duration: 0.01ms !important
A toggle button allows users to override this preference in-app

Pause control

Global pause (button or Esc): Stops all orbs. Paused orbs freeze in their document position and don't move when the user scrolls.
Individual pause (click or Space on a focused orb): Only that orb stops. Other orbs keep moving. This allows users to control exactly which elements are in motion.
The global pause button reflects the aggregate state. If all orbs are individually paused, it shows "Play"; if all are moving, it shows "Pause".

Text content and layout

Dual rendering: pretext stage + native HTML

Implementation details behind the dual layout described above:

Pretext visual stage (aria-hidden="true"): Each line is an absolutely positioned <div> laid out by layoutNextLine(), wrapping around orbs as circular obstacles. The stage's height is computed from the lowest line position.
Native HTML article: When the pretext stage is active, the <article lang="es"> is visually hidden with position: absolute; left: -9999px (not display: none, so AT still reads it).
A useNativeLayout state derived from window.outerWidth / window.innerWidth decides which mode is active.

Viewport	Columns (both modes)
> 1000px	3 columns
641-1000px	2 columns
≤ 640px	1 column

Text wrapping around orbs

In the pretext stage, each orb's position and radius are converted to a circular obstacle via orbToObstacle(). The layout engine (layoutAllText()) feeds these obstacles to layoutNextLine(), which shortens or shifts lines to flow around the orbs in real time as they move.

Headline fitting

The headline is dynamically sized using fitHeadline(), which uses pretext's layoutWithLines() to find the largest font size that fits the headline within the available width and a max height (35% of viewport, or 20% on short screens). Each headline line is rendered as a separate absolutely positioned element.

Drop cap

In the pretext stage, the first character of the first paragraph is rendered as a positioned <div> spanning 3 body lines in height. The layout engine reserves a rectangular region for the drop cap and flows the first paragraph's text around it. In native mode, CSS ::first-letter provides the same effect.

Dynamic header clearance

The article's padding-top uses a CSS custom property --header-h set by a ResizeObserver on the fixed header. In the pretext stage, the top gutter is computed as Math.max(GUTTER, headerHeight + 8). This ensures content is never hidden behind the header at any zoom level or viewport size.

Mobile and responsive behavior

Orbs and pretext stage hidden on small screens and high zoom

At the 500px / 150%-zoom threshold, React conditionally unmounts the orb <section> and the pretext stage entirely (not display: none), and useNativeLayout also halts the renderFrame loop so no layout work runs in the background.

Zoom detection uses window.outerWidth / window.innerWidth: when the user zooms in, innerWidth shrinks while outerWidth stays constant, giving the actual zoom ratio.

Collapsible header at high zoom

At 200%+ zoom or viewports below 500px, the header switches to a compact mode where all controls and keyboard shortcuts collapse behind a native <details>/<summary> toggle, preventing the fixed header from consuming the viewport at high magnification.

A ResizeObserver on the header keeps the --header-h CSS custom property in sync as it expands or collapses, so article content always clears it without overlap.

Mobile header and footer

On screens below 640px:

The header collapses to a single toggle (same <details>/<summary> mechanism as high zoom)
The footer stacks vertically (stats centered, credits below)
Button text and hint font sizes reduce for touch targets
Text reflows to a single readable column

Scroll snapping

html { scroll-snap-type: y proximity; scroll-behavior: smooth; } snaps near-alignments without trapping keyboard scroll (Space, Page Down, arrows keep working because the type is proximity, not mandatory). Under prefers-reduced-motion: reduce, both properties fall back to auto / none.

WCAG success criteria

Criterion	Level	Status	Notes
1.3.1 Info and Relationships	A	Pass	Semantic HTML conveys structure programmatically
1.3.2 Meaningful Sequence	A	Pass	DOM order matches visual reading order
1.3.4 Orientation	AA	Pass	Layout adapts to portrait and landscape
1.4.1 Use of Color	A	Pass	Pause state uses opacity + SR announcement, not color alone
1.4.3 Contrast (Minimum)	AA	Pass	All text meets 4.5:1 ratio
1.4.4 Resize Text	AA	Pass	Native HTML reflows at 200% zoom; orbs removed at 150%+ to prevent obstruction
1.4.10 Reflow	AA	Pass	CSS columns reflow to single column at 320px width, no horizontal scroll
1.4.11 Non-text Contrast	AA	Pass	Focus indicators meet 3:1 against adjacent colors
2.1.1 Keyboard	A	Pass	All functionality available via keyboard
2.1.2 No Keyboard Trap	A	Pass	`scroll-snap-type: proximity` (not `mandatory`), no focus traps
2.2.2 Pause, Stop, Hide	A	Pass	Global and per-orb pause controls, `Esc` shortcut
2.3.3 Animation from Interactions	AAA	Pass	`prefers-reduced-motion` respected, manual toggle available
2.4.1 Bypass Blocks	A	Pass	Landmark navigation via `<header>`, `<main>`, `<footer>`
2.4.3 Focus Order	A	Pass	Tab order follows logical document structure
3.1.1 Language of Page	A	Pass	`lang="en"` on `<html>`, `lang="es"` on Spanish text
3.1.2 Language of Parts	AA	Pass	Spanish text scoped with `lang="es"`
4.1.2 Name, Role, Value	A	Pass	Buttons have labels, toggles have `aria-pressed`, live regions announce changes

Tech stack

Claude calculations, editing and README writing.
React 19
TypeScript 5.9
Vite 8
@chenglou/pretext 0.0.3
Atkinson Hyperlegible, font designed by the Braille Institute for maximum readability

Linkedin
Github**

Accessibility: 2026 predictions

Mica — Sat, 03 Jan 2026 10:44:51 +0000

I have been in the field for almost 6 years and talking (or writing) about accessibility had always been tough in the tech area but NOW it is insufferable.

Nowadays, accessibility it is a hot topic, everyone want to get profit from it and be compliant (which is okay, taking in consideration the European Accessibility Act entering the game). Internet is full of bullshit post generated with AI, talking about the same shit over and over again that nobody reads because they are just empty words with no actual substance.

This is not a anti-AI post. I consider it a valuable tool to boost our job. But, what happen when we forget our human condition in order to gain money and forget that we are building product not only for AI search robots but for HUMANS?

Stop using overlays for accessibility.
Stop using AI for writing posts, use it just for corrections.
Use your hands and your brain.
Think before writing.
Start talking with actual accessibility web professionals.
Talk with actual users with disabilities.

Not everything is money and speed. Behind the computer there are people. Do not forget that.

pd: the title is just a clickbait for my post-rage lol

Accessible components: Pagination

Mica — Tue, 29 Oct 2024 16:58:05 +0000

Today, we're going to look at how to create pagination from scratch and make it accessible and reusable. I hope it’s helpful, and please leave your comments at the end of the post!

Github: https://github.com/micaavigliano/accessible-pagination
Proyecto: https://accessible-pagination.netlify.app/

Custom hook to fetch data

const useFetch = <T,>(url: string, currentPage: number = 0, pageSize: number = 20) => {
  const [data, setData] = useState<T | null>(null);
  const [loading, setLoading] = useState<boolean>(true);
  const [error, setError] = useState<boolean>(false);

  useEffect(() => {
    const fetchData = async() => {
      setLoading(true);
      setError(false);

      try {
        const response = await fetch(url);
        if (!response.ok) {
          throw new Error('network response failed')
        }
        const result: T = await response.json() as T;
        setData(result)
      } catch (error) {
        setError(true)
      } finally {
        setLoading(false);
      }
    };

    fetchData()
  }, [url, currentPage, pageSize]);

  return {
    data,
    loading,
    error,
  }
};

We'll create a custom hook with a generic type. This will allow us to specify the expected data type when using this hook.
We'll expect three parameters: one for the URL from which we'll fetch the data, currentPage, which is the page we're on (default is 0), and pageSize, which is the number of items per page (default is 20, but you can change this value).
In our state const [data, setData] = useState<T | null>(null);, we use the generic type T since, as we use it for different data requests, we'll be expecting different data types.

Pagination

To make pagination accessible, we need to consider the following points:

Focus should move through all interactive elements of the pagination and have a visible indicator.
To ensure good interaction with screen readers, we must correctly use regions, properties, and states.
Pagination should be grouped within a <nav> tag and contain an aria-label identifying it specifically as pagination.
Each item within the pagination should have an aria-setsize and an aria-posinset. Now, what are these for? Well, aria-setsize is used to calculate the total number of items within the pagination list. The screen reader will announce it as follows:

aria-posinset is used to calculate the position of the item within the total number of items in the pagination. The screen reader will announce it as follows:

Each item should have an aria-label to indicate which page we’ll go to if we click on that button.
Include buttons to go to the next/previous item, and each of these buttons should have its corresponding aria-label.
If our pagination contains an ellipsis, it should be correctly marked with an aria-label.
Every time we go to a new page, the screen reader should announce which page we are on and how many new items there are, as follows:

To achieve this, we’re going to code it as follows:

const [statusMessage, setStatusMessage] = useState<string>("");

useEffect(() => {
    window.scrollTo({ top: 0, behavior: 'smooth' });
    if (!loading) {
      setStatusMessage(`Page ${currentPage} loaded. Displaying ${data?.near_earth_objects.length || 0} items.`);
    }
  }, [currentPage, loading]);

When the page finishes loading, we’ll set a new message with our currentPage and the length of the new array we’re loading.

Alright! Now let’s take a look at how the code is structured in the pagination.tsx file.

The component will require five props.

interface PaginationProps {
  currentPage: number;
  totalPages: number;
  nextPage: () => void;
  prevPage: () => void;
  goToPage: (page: number) => void;
}

currentPage refers to the current page. We’ll manage it within the component where we want to use pagination as follows: const [currentPage, setCurrentPage] = useState<number>(1);
totalPages refers to the total number of items to display that the API contains.
nextPage is a function that will allow us to go to the next page and update our currentPage state as follows:

const handlePageChange = (newPage: number) => {
    setCurrentPage(newPage); 
  };

  const nextPage = () => {
    if (currentPage < totalPages) {
      handlePageChange(currentPage + 1);
    }
  };

prevPage is a function that will allow us to go to the page before our current page and update our currentPage state.

const prevPage = () => {
    if (currentPage > 1) {
      handlePageChange(currentPage - 1);
    }
  };

goToPage is a function that will need a numeric parameter and is the function each item will use to navigate to the desired page. We’ll make it work as follows:

const handlePageChange = (newPage: number) => {
    setCurrentPage(newPage); 
};

To bring our pagination to life, we need one more step: creating the array that we’ll iterate through in our list! For that, we should follow these steps:

Create a function; I’ll call it getPageNumbers in this case.
Create variables for the first and last items in the list.
Create a variable for the left-side ellipsis. I’ve decided to place my ellipsis after the fourth item in the list.
Create a variable for the right-side ellipsis. I’ve decided to place my ellipsis just before the last three items in the list.
Create a function that returns an array with 5 centered items: the current page, two previous items, and two subsequent items. If needed, we’ll exclude the first and last pages. const pagesAroundCurrent = [currentPage - 2, currentPage - 1, currentPage, currentPage + 1, currentPage + 2].filter(page => page > firstPage && page < lastPage);
For our final variable, we’ll create an array that contains all the previously created variables.
Finally, we’ll filter out null elements and return the array. This array is what we’ll iterate through to get the list of items in our pagination as follows:

<ol className='flex gap-3'>
          {pageNumbers.map((number) => {
            if (number === 'left-ellipsis' || number === 'right-ellipsis') {
              return (
                <span key={number} className='relative top-5' aria-label='ellipsis'>
                  ...
                </span>
              );
            }
            return (
              <li aria-setsize={totalPages} aria-posinset={typeof number === 'number' ? number : undefined} key={`page-${number}`}>
                <button
                  onClick={() => goToPage(Number(number))}
                  className={currentPage === Number(number) ? 'underline underline-offset-3 border-zinc-300' : ''}
                  aria-label={`go to page ${number}`}
                  aria-current={currentPage === Number(number) && 'page'}
                >
                  {number}
                </button>
              </li>
            );
          })}
        </ol>

And that’s how to create a reusable and accessible pagination! Personally, I learned how to build pagination from scratch the hard way because I had to implement it in a live coding session. I hope my experience helps you in your career and that you can implement it and even improve it!

You can follow me:
linkedin: https://www.linkedin.com/in/micaelaavigliano/

Best regards,
Mica <3

DEV Community: Mica

Accessible and Functional Quantity Spinbutton Pattern

Introduction

Expected behaviors

Keyboard

Screen Readers

NVDA Navigation

VoiceOver Navigation

Gestures VoiceOver - iOS

Gestures Talkback - Android

Pattern A: APG (ARIA Authoring Practices Guide) Spinbutton by W3C

Functional Example – APG

APG code

Conclusion for the APG Spinbutton Pattern

Pattern B: Native HTML solution

Functional Example – HTML

HTML native code

Conclusion for the HTML native solution

Final Thoughts

HTML tags that will improve your e-commerce experience

Understanding when to use <ins>, <del> and <s> HTML tags

Implicit ARIA Mapping: role="deletion" and role="insertion"

Understanding the Accessibility Tree Mapping

How we provide context for combinations without native support on the Accessibility Tree

CSS Styling Tips

Customizing <del> and <s>

Customizing <ins>

Visual Hiding Utility

Resources and Documentation

Master price tags

Understanding when to use <ins>, <del> and <s> HTML tags

Implicit ARIA Mapping: role="deletion" and role="insertion"

Understanding the Accessibility Tree Mapping

How we provide context for combinations without native support on the Accessibility Tree

CSS Styling Tips

Customizing <del> and <s>

Customizing <ins>

Visual Hiding Utility

Resources and Documentation

Learn how to build a disclosure component using the native HTML details tag

Requirements to have a functional disclosure

Anatomy of the details tag

Attributes

CSS Strategies to Style The Disclosure Component

How to style summary

::marker – Code Snippet

::marker – Functional Example

Removing Native Disclosure Icon – Code Snippet

Removing Native Disclosure Icon – Functional Example

Bye, bye div to generate content!

Expandable/Collapsible Content – CSS Snippet

Expandable/Collapsible Content – Functional Example

Keyboard Navigation

Screen Readers

Use cases

What is going on?

How to write an accessible price tag for e-commerces

Understanding when to use <del> and <s> HTML tags

Implicit ARIA Mapping: role="deletion" and role="insertion"

Understanding the Accessibility Tree Mapping

How we provide context for combinations without native support on the Accessibility Tree

CSS Styling Tips

Customizing <del> and <s>

Customizing <ins>

Visual Hiding Utility

Resources and Documentation

Link or Button, that is the question.

What is a Link?

Definition

Semantic

Keyboard Interaction

Screen Reader Interaction

Bad Practice

What is a button?

Definition

Semantic

Keyboard Interaction

Screen Readers Interaction

Bad Practice

Which one should I use: link or button?

Understanding when to use `<ins>`, `<del>` and `<s>` HTML tags

Customizing `<del>` and `<s>`

Customizing `<ins>`

Understanding when to use `<ins>`, `<del>` and `<s>` HTML tags

Customizing `<del>` and `<s>`

Customizing `<ins>`

Understanding when to use `<del>` and `<s>` HTML tags

Customizing `<del>` and `<s>`

Customizing `<ins>`

`prefers-reduced-motion` support