What is an Accessible Layout in Web and Mobile?

What is an accessible layout?

An accessible layout is a page or screen structure that people can read, navigate and operate regardless of ability, device or settings. The order of content is logical, nothing breaks at high zoom or on a small screen, and controls are big enough to hit. It is one part of WCAG, the standard most laws and procurement rules point to.

How an accessible layout works

Layout accessibility rests on a few habits that show up in the POUR principles: perceivable, operable, understandable, robust.

• Structure in the HTML, not just in the CSS. Use header, nav, main and footer landmarks and a real heading outline, so a screen reader user can jump around. Add ARIA only where native elements cannot do the job.
• Reading and focus order follow the visual order. Tabbing should move through the page the way the eye does, see keyboard navigation order. Reordering with CSS grid or flexbox can silently break this.
• Reflow. WCAG 2.2 success criterion 1.4.10 (Level AA) asks that content can be shown without loss of information and without two-dimensional scrolling at a width equal to 320 CSS pixels (and 256 CSS pixels high for horizontal scrolling), except for parts that need a two-dimensional layout, such as maps or data tables.
• Resizable text. Criterion 1.4.4 (AA) requires that text can be resized up to 200 percent without assistive technology and without loss of content or function.
• Orientation. Criterion 1.3.4 (AA) says content should not be locked to portrait or landscape unless a specific orientation is essential.
• Target size. Criterion 2.5.8 (AA, new in WCAG 2.2) sets a minimum of 24 by 24 CSS pixels for pointer targets, with exceptions for enough spacing, inline links in text, equivalent controls and browser-controlled elements.

Example

A shop page shows a product grid with a filter sidebar. At 320 CSS pixels wide the sidebar collapses into a "Filters" button above the grid, the grid becomes one column, and the whole page scrolls only vertically. Tab order goes header, filters, products, footer. Zoomed to 200 percent, the price and the "Add to cart" button stay visible and tappable. Nothing on the page forces landscape.

Common mistakes

• Fixed-width containers and pixel font sizes that force sideways scrolling when zoomed.
• Using CSS order, absolute positioning or tabindex values above 0 so the focus order no longer matches the screen.
• Icon-only buttons and tightly packed links smaller than 24 by 24 CSS pixels.
• Headings picked for their size instead of their level, so the outline is meaningless.
• Locking a mobile app or web view to one orientation for no essential reason.
• Testing only with a mouse on a large monitor.

Layout, testing and monitoring

Layout is easy to break in a release, so check it on real viewports and keep checking. A design built mobile first tends to reflow well by default. Automated tools catch only part of the problems: they can flag missing landmarks or low contrast, but not whether the order makes sense. Pair them with a manual keyboard and zoom pass. LoadFocus page speed monitoring runs scheduled Lighthouse audits that track an Accessibility score next to performance, from 25 cloud regions, which helps you see a regression soon after it ships. For the wider argument see why performance testing should include accessibility.

FAQ: accessible layout

What does reflow mean in WCAG?

Reflow means content adapts to a narrow viewport, equal to 320 CSS pixels wide, without loss of information and without needing to scroll both vertically and horizontally. Maps, data tables and similar content that needs two dimensions are exempt.

Is a responsive layout automatically accessible?

No. Responsive design handles screen size, but accessibility also needs a logical reading and focus order, usable touch targets, resizable text and meaningful headings and landmarks.

How big should touch targets be?

WCAG 2.2 criterion 2.5.8 sets a minimum of 24 by 24 CSS pixels for pointer targets, with exceptions such as enough spacing around smaller targets or links inside a sentence. Larger targets are easier to hit and are a good default on phones.

Can I lock my app to portrait?

Only if a specific orientation is essential, as WCAG 1.3.4 puts it. Otherwise support both, because some users mount their device in a fixed position.

Which WCAG level should a layout meet?

Reflow, resize text, orientation and target size minimum are all Level AA, which is the level most laws and contracts ask for.