Motta Industries Blog

A mobile page can fit the screen and still make its controls difficult to use. Small targets invite inaccurate taps. A sticky header can cover the control reached by a keyboard. A disappearing focus indicator can leave someone unsure where the next action will happen.

These details are connected, but they are not interchangeable. Making a button larger does not repair a hidden focus location, and removing a sticky element does not automatically give a control an understandable name. Review the whole interaction rather than treating a responsive screenshot as proof of accessibility.

For a small business website, start with an important task: choosing a product option, opening navigation, or completing an enquiry. Examine its controls, their spacing, and their behavior as the page scrolls or changes. The aim is a usable route through the task, supported by specific checks rather than a blanket claim of compliance.

Measure the interactive target, not just the icon

The fixed October 2023 WCAG 2.2 Recommendation includes Success Criterion 2.5.8, Target Size Minimum, at Level AA. It specifies a target of at least 24 by 24 CSS pixels for pointer inputs, with defined exceptions. That is not a rule that every visible icon must be drawn at that size.

A small symbol can sit inside a larger interactive area. Conversely, a large-looking label may have a surprisingly small clickable region if the implementation makes only part of it interactive. Ask the developer to inspect the actual target rather than measuring decorative artwork alone.

CSS pixels are not the same as counting physical display pixels from a photograph. Use appropriate browser inspection and testing methods. A screenshot or an AI illustration cannot establish the implemented target dimensions, spacing, or behavior on the live page.

Understand the spacing exception accurately

Under the criterion’s spacing exception, an undersized target can qualify when a 24 CSS pixel diameter circle centered on its bounding box does not intersect another target or the corresponding circle for another undersized target. This is a geometric condition, not simply advice to add some margin.

That distinction matters in compact controls such as product filters, pagination, and icon toolbars. Enlarging one target can also change its relationship with neighboring targets. The developer should review the whole group, not declare each icon acceptable in isolation.

Other exceptions concern an equivalent qualifying control on the same page, inline targets, unmodified user-agent controls, and essential presentation. Apply the actual criterion and its conditions rather than treating the word exception as permission to ignore difficult cases. Prefer a comfortably usable design where practical instead of relying on an exception without understanding the result.

Do not confuse the minimum with the enhanced criterion

The fixed June 2018 WCAG 2.1 Recommendation records the 44 by 44 CSS pixel Target Size criterion at Level AAA, with its own exceptions. WCAG 2.2 retains an enhanced target-size criterion. The larger figure is not the same as claiming that every target must be 44 pixels to meet the newer Level AA minimum.

A business can choose generous controls as a design preference without misstating the conformance level or assuming one threshold alone proves accessibility. Consider how customers use the control, neighboring actions, and the consequences of an accidental activation.

For example, a destructive action should not be crowded beside a routine selection merely because each control passes an isolated size check. Labeling, confirmation where appropriate, and the surrounding interaction still matter. Dimensions are one part of the design, not the entire decision.

Test keyboard focus on a mobile layout

Mobile devices are not exclusively touch-operated. A narrow layout may be used with an external keyboard or other input arrangements. Follow the task using keyboard navigation and identify which control receives focus at each step. The focused component should be understandable and operable, not merely somewhere in the document.

The fixed February 2015 H91 technique for HTML controls and links explains how standard elements support keyboard operation and assistive-technology interoperability. It is an informative technique, not an extra normative requirement or the only possible conforming implementation. It provides a useful reason to question custom controls that discard ordinary behavior without replacing it reliably.

Check names and roles as well as visual appearance. A control resembling a button still needs the appropriate implemented behavior. Native elements can help, but they do not excuse unclear labels, hidden focus, or an inaccessible surrounding workflow.

Keep sticky content from hiding the active control

WCAG 2.2’s Focus Not Obscured Minimum criterion, 2.4.11 at Level AA, requires that a component receiving keyboard focus is not entirely hidden by author-created content. A sticky header, bottom bar, cookie panel, or other overlay can create that problem even when the underlying page scrolls normally.

The enhanced criterion at Level AAA is stricter: no part of the focused component is hidden by author-created content. Do not report the minimum criterion as if it required the enhanced result, or use the minimum wording as a design target that deliberately leaves most of a control obscured.

Inspect the active control while moving forward and backward through the page. Test when banners appear, menus expand, and validation messages change the layout. A header that behaves correctly at the top of the page can still obstruct a later field or action after the browser scrolls it into view.

Treat visible focus as a separate check

A component can remain on screen while its focus indicator is absent or difficult to distinguish. It can also show a visible indicator while being partly or entirely covered. These are related observations, but one does not establish the other.

Review the applicable visible-focus criteria along with obscuration. Avoid removing browser focus styling simply because it does not match the visual design. If it is replaced, the new treatment needs to remain useful across the relevant states and backgrounds.

Motta Industries’ user-experience design services can help connect those details to a coherent interaction. The discussion should identify the actual task and failure, not reduce accessibility to a preferred outline color or a single automated result. Keep a record of what was evaluated and what remains outside the review.

Check what happens when the page changes

A product selection can reveal new controls. An error can insert a message above a field. A consent panel can occupy space after someone has started a task. Review those states rather than limiting inspection to the initial layout with every panel closed.

Increase text size and examine the narrow layout under appropriate test conditions. Check whether controls overlap, labels become ambiguous, or important actions move beneath persistent content. Document the tested settings instead of assuming that one device represents every supported environment.

Use responsive design work to address the relationship between layout and interaction. Fitting content into a viewport is not the same as preserving a usable sequence. A good revision considers how the controls behave when content grows, errors appear, and available space changes during the task.

Make the repair ticket specific enough to reproduce

Record the page, relevant state, viewport or device conditions, input method, and steps that expose the barrier. Identify the expected behavior and observed result. Include a screenshot or recording when useful, while keeping private information out of the evidence.

Distinguish a measured target-size issue from an obscuration issue or an unclear focus indicator. A developer may need different changes for each. An instruction to make mobile accessibility better is less actionable than a record showing which control becomes hidden after a particular panel appears.

Define the verification route before closing the ticket. Recheck the original failure, neighboring controls, and relevant task states. A larger hit area should not steal another control’s interaction, and an adjusted header should not cover content elsewhere. Repairs need regression checks, not only a favorable view of the changed component.

Review a compact control group together

Consider an illustrative row of three controls, each measuring 20 by 20 CSS pixels, with centers 20 CSS pixels apart. They do not meet the 24 by 24 minimum size. The spacing exception also cannot be assumed: the corresponding 24-pixel diameter circles overlap in this arrangement. Another applicable exception would need its own justification.

Simply enlarging the interactive areas while leaving the centers unchanged can create overlapping targets. The repair should adjust the group rather than make each control bigger and hope the browser resolves the conflict. Inspect which action actually receives a pointer activation near the boundaries.

Now follow keyboard focus through the same group after the page scrolls beneath a sticky bar. Target dimensions do not establish whether the active component remains visible. A visible outline does not establish that its control is unobscured. Keep those findings separate in the ticket even when the repair touches the same styling.

The numbers here describe a hypothetical layout, not a measured customer site or a complete conformance example. Evaluation needs the implemented geometry, other nearby targets, applicable exceptions, and the criterion’s notes. Read the notes about user-movable and user-opened content when assessing obscuration, rather than reducing the standard to a slogan.

After a revision, repeat the pointer and keyboard checks at the narrow layouts and states. Record the result, any remaining limitation, and who is responsible for the next step. This produces a repair record instead of a larger-looking screenshot.

Use a task walkthrough, not a compliance shortcut

Imagine a hypothetical plant shop with product filters and a sticky information bar. A customer needs to select a pot size, review the result, and open an enquiry route. The review follows that sequence with touch and keyboard input, including expanded filters and error states.

The team measures targets and spacing, observes focus visibility, and checks whether persistent content hides the active component. It records exceptions using the criterion’s actual conditions rather than assuming that compact design makes an exception automatic. Any unresolved barrier stays visible in the work record.

This hypothetical walkthrough is not a complete accessibility assessment, and no photograph of a person using a phone proves a successful or accessible interaction. These details should be evaluated alongside the broader applicable requirements and, where needed, qualified testing with appropriate assistive technologies and users.

Keep the public statement accurate

If the business publishes an accessibility statement, it should describe the actual scope and known position rather than repeat an unsupported claim that the website is fully accessible. Update that information when meaningful findings or changes affect what visitors should know.

Motta Industries’ own accessibility statement is an example of a company statement, not evidence that another website conforms or a promise of a particular evaluation service. Keep that distinction clear when discussing accessibility information with a developer.

Target dimensions, spacing, visible focus, and unobscured controls are practical details with separate tests. Address them together in the customer’s task, record the limits of the review, and make the next improvement specific enough to verify.