Tick the box to accept the terms.
``` ```js form.addEventListener('submit', (event) => { if (terms.checked) return; event.preventDefault(); termsError.hidden = false; terms.setAttribute('aria-invalid', 'true'); terms.focus(); }); terms.addEventListener('change', () => { if (!terms.checked) return; termsError.hidden = true; terms.removeAttribute('aria-invalid'); }); ``` The button is always reachable, always readable, and always does something. Pressed too early, it shows the error beside the checkbox and moves focus there, where a screen reader reads the label, the invalid state and the error. There is no disabled state to expose, so there is nothing to get wrong. ## After: aria-disabled with the reason beside it ```htmlTick the box to accept the terms before you place your order.
``` ```js terms.addEventListener('change', () => { place.setAttribute('aria-disabled', String(!terms.checked)); placeWhy.hidden = terms.checked; }); form.addEventListener('submit', (event) => { if (place.getAttribute('aria-disabled') === 'true') event.preventDefault(); }); ``` ```css .btn[aria-disabled="true"] { background: #e6e2dc; color: #57524c; cursor: not-allowed; } ``` `aria-disabled` exposes the state, as "Place order, button, dimmed" or "unavailable", but keeps the button in the Tab order, so keyboard and screen reader users reach it and hear the reason linked to it. Unlike `disabled`, it doesn't stop anything, so the script has to block the submit itself, including Enter in a text field, which also submits the form. The faded look is drawn from the attribute, and its text is kept readable. ## After: native disabled with a visible reason ```htmlTick the box to accept the terms before you place your order.
``` ```js terms.addEventListener('change', () => { place.disabled = !terms.checked; placeWhy.hidden = terms.checked; }); ``` This is the smallest change: the browser exposes the state and blocks every way of pressing, and the reason is in visible text right above the button, where people reading the page meet it. It passes 4.1.2, but it is not enough on its own. Tab still skips the button, so a keyboard user or a screen reader user moving with Tab never reaches it, and the reason is only found by reading. Write the reason in readable text, not in the faint button. ## Which option to use All three pass 4.1.2. Leave the button enabled and explain when it is pressed: it keeps the button where everyone can find and read it, gives a reason only when someone needs one, and uses the error handling the form needs anyway. Use `aria-disabled` when the design must show that the button isn't ready yet, accepting that the script, not the browser, has to stop the action. Native `disabled` with a visible reason is the smallest change to an existing disabled button, but people moving with Tab still pass it by, so treat it as a step on the way rather than the end. ## Implementation decisions A button that is unavailable for a moment, rather than waiting on the person, is a different case. While an order is being sent, keep the button where it is, mark it `aria-disabled="true"` and ignore further presses, and say "Placing your order" in a status message. A native `disabled` there drops focus to the page body in some browsers, and the person loses their place. Disabled links don't exist in HTML. A link with a `disabled` class is still a link. When a link must not be followed, remove its `href`, so it is no longer a link or a Tab stop, or turn it into a button with `aria-disabled`. The faded look is where the contrast goes. Disabled controls are exempt from the contrast criteria, but the exemption doesn't make them readable. Draw an unavailable button with readable text and change something besides colour, such as a dashed border. Native `disabled` buttons are drawn in `GrayText` in forced colors; a button styled from `aria-disabled` loses that look unless you add a `forced-colors` rule. Several reasons at once need several messages. When Place order waits for a delivery slot and the terms, list both beside the button, or let the enabled button show an error summary of everything that is missing, as in [error summaries that list every problem](/learn/error-summary). See [form errors that say what went wrong](/learn/accessible-form-errors) for the error beside each field. Component libraries often expose a `disabled` prop that sets the attribute and an option, such as `focusableWhenDisabled`, that sets `aria-disabled` instead. Check which one the shared button uses, and which element in it takes focus. ## Verify the fix 1. Tab through the form from the top, and confirm focus reaches the button, or that, with native `disabled`, the reason is in visible text beside it. 2. With a screen reader, move to the button and confirm its state is announced the same way it is drawn: unavailable when it looks unavailable, and not when it doesn't. 3. Confirm the reason is read: through `aria-describedby` on focus, as the error when the button is pressed, or when reading down the page. 4. Press the button with a click, Enter and Space before the form is ready, and press Enter in a text field. Confirm nothing is submitted and you are told what is missing. 5. Complete the form, and confirm the button looks and is announced as ready, and submits once. 6. In forced colors and at 200% zoom, confirm the button and its reason can still be seen and read. Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared button component changes. ## Limits This is a starting pattern, not a guarantee for every form. Screen readers word `aria-disabled` and `disabled` differently ("dimmed", "unavailable", "disabled"), and some read `aria-describedby` only after a pause or on request. The error wording and its place on the page depend on the rest of your form. Test the whole journey, from an empty form to a placed order, with the assistive technology your users have.