Accessibility in Design

WCAG stands for Web Content Accessibility Guidelines. It is the main reference used to evaluate digital accessibility and is organized around four principles:

Semantic HTML tells the browser what an element is. Visual appearance does not define its meaning. If something looks and behaves like a button it should normally be built as a <button>

There is no WCAG rule requiring an input to be 44px high. A 32px input is not automatically inaccessible.

WCAG 2.2 AA sets a 24 × 24 CSS px minimum pointer target with some exceptions. The 44 × 44 CSS px target belongs to the stricter AAA criterion.

WCAG AA allows targets smaller than 24 × 24px in some cases when enough spacing exists around them. In a tightly packed interface, small targets become more difficult because users can accidentally activate a neighbouring control.

This guidance focuses specifically on highly compact grid variants where target size becomes harder to manage. Above 32px, targets generally become easier to interact with and move closer to the preferred touch-friendly sizes.

Focusing specifically on target size, these recommendations work well for highly compact interfaces while staying within the WCAG 2.2 AA baseline.

Input inside a cell

When row data is edited through a dedicated input inside the cell, 28px height is a good minimum for the most compact variant. It stays above the 24px AA baseline while allowing the grid to remain dense.

Entire cell is editable

When the whole cell acts as the editable target, use 32px as the minimum. While 28px can still satisfy the target-size requirement, 32px gives users a larger area for selecting the correct cell in a dense editable grid.

<Tab> - moves forward between interactive elements.

<Shift + Tab> - moves backward.

Keyboard order should follow a meaningful sequence.

Bad Navigation:

Good Navigation:

Every keyboard-focused control needs a visible focus indication.

Reaching something isn't enough. Different controls have expected keyboard interactions.

Focus starts on a control on the main page.

Then user clicks o:

Modal (pop-up) opens.

Focus should move inside the modal to an intentional starting point. It should not remain on the page behind it.

The right starting point depends on the content and purpose of the modal. There is no universal element that should always receive initial focus.

Avoid making keyboard and assistive technology users tab through unnecessary controls before reaching the main task. For a simple form modal, for example, moving focus directly to the first input or relevant option can be more efficient than starting on the title or close button.

When a modal closes, focus should usually return to the control that opened it.

What if the focused element no longer exists?

Consider a user deleting a row from a grid. The row and the control that previously had focus disappear so focus needs a new logical destination.

Depending on the situation, focus could move to:

• The next row
• The previous row if there is no next row
• The grid's empty state if the last remaining row was deleted

If the grid becomes empty, communicating "No data available" is useful feedback because it confirms the result of the action.

What about a confirmation snackbar?

A snackbar can announce that the deletion was successful without moving keyboard focus to it. Focus can move directly to the next logical location in the grid while the snackbar message is communicated to assistive technology.

If a user activates a control that reveals additional content, focus usually stays on the control that triggered the change.

Once clicked, additional details appear:

The button changes from "Show more" to "Show less" but keyboard focus stays on the button. The user can then continue navigating normally into the newly revealed content.

The expanded state also needs to be communicated to assistive technology, usually with aria-expanded.

General Rule

• Expanding or revealing inline content: Keep focus on the control that triggered it.
• Opening a modal or overlay: Move focus into the newly opened area because the user's interaction context has changed.

Scenario 1

If a longer form is submitted and several fields are invalid, users need a clear way to understand what went wrong and find each problem.

When there is no real-time validation, an error summary at the beginning of the form is a good approach. When the summary appears, move focus to it so the screen reader announces the errors.

Each error in the summary can link directly to the corresponding field so keyboard users can quickly jump to the problem.

The affected fields should also:

• Show an invalid state
• Display an error or hint explaining the problem
• Have the error message programmatically associated with the input

This keeps the explanation available when the user reaches the field.

Scenario 2

For real-time validation, validate the field when the user leaves it if appropriate for that input.

If the value is invalid:

• Show the inline error
• Mark the field as invalid
• Associate the error message with the field
• Announce the new error to the screen reader
• Keep focus moving normally to the next field

Focus does not need to jump back to the invalid input or move to the error message. The user can continue through the form and return to the field when needed.

Developer requirement: Invalid state + associated error + live announcement.

Scenario 3

If two password fields do not match after submission, use an error summary and move focus to it so the screen reader announces the problem.

Anchor links are less useful here because the mismatch does not tell us which of the two values is incorrect. The user can navigate back through the fields and correct the appropriate value.

Rule: Move focus when users need to be redirected after submission. For inline validation during navigation, announce the error without interrupting their focus flow.