Barrierefreiheit | Blog | Tutorials and know-how

How can you identify accessibility issues relating to font sizes and zoom?

Eckhard Schneider
Published by Decareto
·
8min read
·
August 31, 2026
decareto-barrierefreiheit-font-sizes-zoom
Table of Contents

You can identify accessibility issues relating to font sizes and zoom by specifically checking whether text can be enlarged to at least 200 per cent without content being cut off, and whether font sizes are defined in relative units such as rem or em. These technical requirements are set out as mandatory in the WCAG success criteria and apply to all websites covered by the Accessibility Enhancement Act (BFSG). The following article answers the most important questions regarding standards, common errors, testing methods and suitable tools.

Which WCAG requirements apply to font sizes and zooming?

WCAG 2.2 specifies in Success Criterion 1.4.4 (Resize Text, Level AA) that text must be able to be enlarged to up to 200 per cent without any loss of content or functionality. Success Criterion 1.4.10 (Reflow, also Level AA) adds that content must be readable without horizontal scrolling at a viewport width of 320 CSS pixels.

In practical terms, this means the following for implementation:

  • Font sizes in relative units: Font sizes should preferably be defined in relative units (rem, em, %). Although modern browsers also scale pixel values when zooming, relative units allow for better adaptation to user settings.
  • Do not lock zooming: The meta tag <meta name="viewport" content="user-scalable=no">actively prevents zooming and contravenes WCAG 1.4.4.
  • Minimum font size for body text: Although WCAG does not specify a minimum size in pixels, in practice 16 px (or 1 rem) is regarded as a guideline for clearly legible body text.
  • Contrast is maintained when zooming: Enlarged text must continue to meet the contrast requirements set out in WCAG 1.4.3.

The BFSG, which has been binding for many companies since June 2025, is based on the European standard EN 301 549, which in turn is based on WCAG 2.1 Level AA. Therefore, anyone who meets the WCAG requirements for font size and zoom is simultaneously fulfilling key obligations under the BFSG.

How can you identify faulty zoom implementations on websites?

The most reliable way to identify faulty implementations of text enlargement is through manual testing in the browser. The quickest test: enlarge the content to 200 per cent (e.g. using Ctrl/Cmd + Plus). If text is cut off, elements overlap, or content or functions are lost, this constitutes a breach of WCAG 1.4.4.

 

Subtitles and image captions are exempt.

Manual testing steps in the browser

Proceed systematically when carrying out the manual zoom test:

  1. Open the website in a recent browser.
  2. Increase the text size in the browser settings gradually to 200 per cent.
  3. Check that all text is still fully visible and that no content is cut off.
  4. Test interactive elements such as buttons, forms and navigation menus for usability.
  5. Switch to a viewport width of 320 px and check whether horizontal scrolling is required (WCAG 1.4.10).

Identifying zoom restrictions in the source code

In the HTML source code, you should specifically search for the viewport meta tag. Variants such as user-scalable=no or maximum-scale=1 are problematic. Such entries block the browser’s native zoom function and constitute a clearly identifiable WCAG violation that can be detected automatically.

What are typical accessibility issues with font sizes?

The most common font size issues on websites are the use of absolute pixel values, base font sizes that are too small, and a lack of responsive adjustments. These errors particularly affect users who rely on browser zoom or system settings for larger text, such as older people or those with visual impairments.

In practice, testers encounter the following patterns of problems particularly frequently:

  • Font size fixed in pixels: CSS rules such as font-size: 12pxcompletely ignore the user’s operating system or browser settings.
  • Base font size too small: Body text smaller than 14 px is difficult to read for many user groups, even those without visual impairments.
  • Line spacing too narrow: WCAG 1.4.12 (Text Spacing) requires that content is not cut off or overlapped when users increase line, character, word and paragraph spacing to the specified values.
  • Lack of responsive adaptation: Font sizes that are easily legible on a desktop are not automatically scaled on mobile devices if responsive CSS units are not used.
  • Headings and labels too small: Form fields, buttons or navigation elements with very small text make them considerably more difficult to use.

Many of these problems do not arise from negligence, but because design specifications are translated into absolute units without taking the impact on accessibility into account.

How do automated and manual testing methods differ?

Automated tests check a website’s HTML and CSS code for measurable violations of guidelines, such as zoom lock or font sizes specified in pixels. Manual tests check whether the website is accessible in real-world use; for example, whether content is still sensibly laid out after zooming in. Both methods complement each other and are not mutually exclusive.

What automated tests can achieve

Automated accessibility tests based on libraries such as axe-core can reliably detect:

  • Viewport meta tags with zoom restriction
  • Font sizes below defined thresholds
  • Missing or incorrect CSS units
  • Violations of text spacing requirements (WCAG 1.4.12)

Estimates suggest that automated tests can detect around 30 to 50 per cent of all WCAG violations. For font size and zoom issues that manifest at the code level, the detection rate is generally higher.

What manual testing achieves

Manual testing reveals what code analysis misses: whether text visually overlaps after zooming in, whether the reading order remains logical, or whether content is technically present but practically inaccessible. The Web Accessibility Initiative (WAI) provides a checklist for quick manual tests that can be used even without extensive testing experience. A good result in an automated accessibility test is a necessary but not sufficient condition for actual accessibility.

Which tools help to identify font size and zoom issues?

Specialised accessibility software solutions, browser developer tools and manual testing methods are available for identifying font size and zoom issues. The choice of the appropriate tool depends on whether individual pages or entire websites are to be systematically checked.

  • Browser developer tools: The developer tools in Chrome, Firefox or Edge allow you to inspect CSS rules directly and check whether font sizes are defined in relative units. The source code viewer displays viewport meta tags at a glance.
  • Axe DevTools (browser extension): This free browser extension from Deque Systems checks the currently open page for WCAG violations, including issues with zoom and font sizes.
  • WAVE (Web Accessibility Evaluation Tool): This tool from WebAIM visualises accessibility issues directly on the page and is well suited for an initial assessment.
  • Automated accessibility software platforms: For the systematic testing of multiple websites or entire website structures, platforms that scan subpages, prioritise results and export reports are suitable. These tools are particularly relevant for agencies and compliance teams that manage many websites.
  • Screen reader tests: Although screen readers are primarily relevant for other accessibility issues, they help to understand the extent to which zoom problems affect overall navigation.

No single tool covers all issues. A combination of automated scanning for the rapid identification of code errors and manual browser testing to assess the actual user experience is recommended. Anyone wishing to check a website for accessibility should use both methods systematically.

When must organisations rectify font size and zoom issues?

Since June 2025, many organisations have been subject to a legal obligation regarding digital accessibility. The Accessibility Enhancement Act (BFSG) requires providers of certain products and services to make their digital offerings accessible in accordance with WCAG 2.1 Level AA. Font size and zoom issues that contravene WCAG 1.4.4 or 1.4.10 are therefore directly relevant.

Specifically, the following applies:

Public bodies: Federal authorities and public institutions have been subject to strict accessibility obligations under the BITV 2.0 since 2019 and 2021 respectively.

Private companies falling within the scope of the BFSG: From 28 June 2025, companies covered by the BFSG must ensure their websites and digital services are accessible. These include, in particular, e-commerce providers, banks and telecommunications companies.Newly designed websites: Regardless of statutory deadlines, every newly developed or fundamentally redesigned website should be designed from the outset to ensure accessible font sizes and zoom compatibility.Prioritisation by severity: Where resources are limited, issues should be prioritised according to their impact. Zoom restrictions that block basic functions should be classified as critical and resolved first.

Even if there is no immediate legal obligation, resolving font size and zoom issues is worthwhile for practical reasons: they improve the user experience for all visitors, not just for people with disabilities.

How decareto helps identify font size and zoom issues

At decareto, we have developed our accessibility software to highlight precisely those issues that are easily overlooked during manual checks. Our platform offers specific support for font size and zoom issues:

  • Automated scan against WCAG standards: Our software checks websites for zoom restrictions in the viewport meta tag, font sizes specified in absolute units, and violations of WCAG 1.4.4, 1.4.10 and 1.4.12 – across all subpages in a single pass.
  • Prioritisation by severity: Issues found are classified according to their impact, from critical to minor, so that you can immediately identify where urgent action is required.
  • Specific recommendations for action: For every issue found, we provide clear guidance on how to resolve it, including a reference to the relevant WCAG success criterion and the HTML code of the problematic element.
  • Continuous monitoring: Hundreds of websites can be monitored continuously. You’ll receive automatic notifications if changes are made that introduce new barriers.
  • Manual additions possible: Issues that can only be identified manually can be documented directly in the report and added to the scan results, providing a complete picture of the accessibility situation.
  • Share and export reports: Completed reports can be shared directly with clients or exported as PDFs, including with a white-label logo for agencies.

A good result in the decareto scan is an important indicator, but it is no substitute for a full manual audit or legal advice. We support your compliance efforts by highlighting technical vulnerabilities and providing you with a structured basis for further action. Try our accessibility software and test your website today, or register now for a free trial.

Related Articles

Social Share:

Explore more related blogs

1min read
·
November 11, 2026
In diesem Leitfaden beschreiben wir die zehn wichtigsten Punkte für die technische Umsetzung und bieten ...
1min read
·
November 10, 2026
How can data protection professionals audit websites with less effort? Find out which GDPR checks ...
1min read
·
November 9, 2026
Why a scan alone isn’t enough, and how to identify, assess and prioritise barriers on ...