Designing for people with low vision
Low vision affects millions of people worldwide, yet it's often overlooked in the design process. The design choices we make, from how we emphasise content to where we position controls, can either empower people to customise their experience or create unnecessary barriers. By understanding these impacts and designing with flexibility in mind, we can create interfaces that truly work for everyone.
If you haven't already, dip into other posts in our Designing for disabilities series:
People we are designing for
The term 'low vision' covers a variety of sight problems among the greater category of seeing disabilities. This includes people with age-related vision loss who may not consider themselves disabled, people with glaucoma who have reduced vision, and people with more severe conditions such as advanced retinitis pigmentosa, often known as tunnel vision. Many people with low vision browse using screen magnification, increasing zoom levels, or a combination of both.
No two people experience vision loss in the same way. Even people with the same condition are affected differently. Vision exists on a spectrum, and people use different assistive technologies and adaptive strategies based on their own level of sight. The beauty of the web is that it inherently supports adaptation to the degree each individual needs, but only when the design and implementation allow it.
Considerations
Design decisions directly shape how people with different levels of vision experience digital interfaces. The choices you make as a content designer, interaction designer, visual designer, or user experience designer can either support adaptation or create unnecessary barriers.
As discussed in our article designing for people with disabilities, inclusive design is not just about implementing requirements such as the Web Content Accessibility Guidelines correctly, but about shaping outcomes that work for how people consume content. Here are some key considerations and how to design experiences for people with low vision.
Provide a clear visual hierarchy
People with low vision often see only a small portion of the screen at any one time, when using zoom or screen magnification. A clear visual hierarchy helps them understand how content is structured and how sections relate to each other, without having to piece that structure together mentally.
One way to achieve this is to ensure that headings (h1 through to h6) visually reflect the relationship between sections of content. Larger font sizes should indicate higher level headings, making the structure of the page clear at a glance.
When different heading levels appear the same size, the relationship between sections becomes unclear. In the following example, the second level headings, "Account Management" and "Billing & Subscriptions" are the same size as the third level subheadings which is confusing as it suggests they are the same hierarchy.
Here's the same page where the different sizes between the second and third level headings make the hierarchy clearer visually.
Provide clear visual grouping
Clear visual grouping of information reduces cognitive load, supports orientation at high zoom levels, and helps people recognise relationships between content quickly and confidently.
There are a number of ways this can be done, including:
- Using background panels or cards: place related content within a shared container with sufficient contrast between the background and surrounding content
- Consistent spacing between sections: increase space between unrelated sections and reduce space within related groups
- Grouping form fields with clear boundaries: use consistent spacing, fieldsets, and visible legends so related inputs are clearly connected
- Clear association between labels and controls: ensure labels sit close to their inputs and are not visually detached
- Visually distinct navigation areas: separate navigation from main content using spacing, borders, or background contrast
The TetraLogical homepage makes use of a few of these techniques including using background colours for panels and a visually distinct main navigation.
The following is the same page again but with the page zoomed within the browser.
Another example, taken from the standards and guidelines page of this website, shows how a background and outline can make a set of disclosures distinct from the rest of the page and each other.
When zoomed by 200% in the browser, much less of the page is visible at once. The background and outline help maintain a clear boundary around each disclosure, making it easier to recognise them as distinct sections rather than isolated fragments of content.
Prioritise key content
One of the Inclusive Design Principles is to "Prioritise content":
Help users focus on core tasks, features, and information by prioritising them within the content and layout.
When content is zoomed or magnified, the visible area of the screen is reduced. Instead of seeing the full page or screen layout, people see a small portion at a time. This could be just a few lines of text on a web page or part of an image and some text. If visual priority is not clear, it becomes harder to tell what is important, what relates to what, and where to focus next.
In the following example of an email application interface, it would appear to have all the features that you would expect, including various mailboxes, an email viewer and a Compose Email button
In languages that run left-to-right, content that has most importance should be present towards the top-left of the page. In this example, arguably the most important feature of an email client, the Compose Email button has been positioned where someone with screen magnification has to go hunting for it and may well miss it, as they would most likely be exploring that area to the top-left:
One workaround is to move the button to the top-left where most people might reasonably expect it to be, and where people with low vision have a chance of discovering it when using screen magnification.
The same priority that you should provide for position of elements carries through to the wording that you use on elements, be that headings, buttons or links. Once again, assuming a left-to-right language, the most important content should be on the left.
A bad example of a heading or link might be "Read more about our hibiscus plants" where simply "Hibiscus plants" does the job. Equally, linking "Can't find what you are looking for? Contact us" places the key information at the end of the link whereas just linking "Contact us" is sufficient.
Group related content or controls
Related content and controls should appear close to each other so their relationship is immediately clear. When elements are visually separated, it can become difficult to understand what belongs together, particularly for people using zoom or magnification where large areas of empty space can make people feel lost.
The following example of a disclosure shows the upside-down triangle, which visually indicates that there is content that may be revealed, to the far right of the text.
This can be problematic for someone browsing with screen magnification or content zoomed, because there is nothing that visually joins that triangle with the disclosure trigger text of "Famous composers". The text also has no other styling that might suggest it's interactive; it does not look like a button, has no underline. It could easily be mistaken as a heading.
By grouping the arrow button to the left of the text, the button remains visible when the screen is magnified and this content is in view.
As noted earlier, in addition to placing the control near to its associated text, this relationship can be reinforced by visually grouping the content.
Other examples of content that should be grouped together include:
- Form errors: place error messages and help text immediately next to the relevant form field so they are clearly associated
- Control labels: position checkbox and radio button labels directly beside their controls so the relationship is obvious
- Calls to action: keep actions such as Edit, Delete, or Select close to the related item description or name, especially within tables
Avoid fixed heights for text content
When laying out blocks of text content side-by-side, typically a designer will want the different blocks to align so it doesn't result in a staggered look.
Take the example below where there are two blocks of content in a banking app. Each block has a background colour and a border that helps it to stand out against the page background.
The amount of text in each panel is roughly equivalent, and the panel heights match. But what happens if the content increases? It’s unlikely the designer intended these panels to have different heights, yet design work often assumes a fixed amount of content. In practice, content varies and can change as people zoom the page or enlarge text, increasing the space content requires.
In other words, the design reflects optimal conditions, where content fits neatly within each panel. In reality, content rarely stays this balanced. As content grows or changes, the layout may start to look more like this:
The problem demonstrated in the image above is one that straddles design and development disciplines. At default size, the design would appear to accommodate some flexibility in the amount of content that may be in each panel. However, if the height of the largest of the two panels is set with the CSS height property, it doesn't allow people with low vision to boost their font sizes without things becoming unusable:
In the example above, the font size has been increased to 200% in the browser, causing it to overflow the fixed height container. The overlapping text is unreadable over the content that follows. This is an extreme example, but it is actually very common with much smaller design elements, notably buttons.
As a designer, it's useful to be aware how a developer might implement a design. Knowing that they could, potentially, set a fixed height to achieve the alignment, and knowing that the content that appears may change and increase encourages a mindset of designing defensively against things breaking.
A better approach is to design the layout so that if the text is updated and increases, it doesn't affect the visual layout. In this instance a stacked layout works better. In a stacked layout, it doesn't matter how much text is in either panel, as each panel can resize to whatever height the content requires it to.
A stacked design by default would certainly prevent that, and protect against those scenarios, including when font size is increased:
Design discoverable notifications
When someone is using zoom or magnification, and only a small area of the screen is visible at a time, notifications may appear outside that area and disappear before they are seen.
Toast notifications are a common example. These temporary messages appear briefly to provide feedback about an action and then disappear automatically. They are often low contrast, visually subtle, and positioned away from the triggering action, making them difficult to notice or connect to what just happened. As a result, important feedback can be missed, leaving the user unsure of the outcome.
In the following example, a toast message is displayed in the bottom-right-hand corner of the screen. It doesn't disappear automatically, instead it remains in place until it's dismissed by clicking the 'x' close button.
A screen magnification user might completely miss it because it's outside the area where they currently have their screen magnification focused.
One solution is to avoid using toast notifications altogether. They are difficult for many people to perceive and use, including both disabled and non-disabled users. GitHub no longer recommends them in its design system documentation instead encouraging more robust notification patterns.
The simplest solution to ensure that people using screen magnification are not excluded is to:
- Place the notification message adjacent to whatever initiated the action that caused the message to display and
- Move focus to that element.
Even if the message is just out of the current screen magnification area, moving focus to it should ensure that it gets seen.
Avoid sticky headers and footers
Sticky headers and footers are interface elements that remain pinned to the top or bottom of the screen while the rest of the page scrolls. They are often used for navigation, branding, or key actions.
At high zoom levels, a fixed header and footer can leave only a narrow strip of space for the main content, increasing scrolling and making it harder to read or complete tasks. They can also obscure content when text is resized, forcing people to pan around the page to see information that would otherwise flow naturally.
In the following video example, the header area remains fixed in place, providing quick access to the navigation at all times. This is viewed in the browser with no magnification. When scrolling through the page, the header only uses a small amount of space at the top of the screen.
In the next example, the page content is zoomed to 400% with the screen size set to 1280px by 720px. This is the equivalent of a 320px by 180px screen, un-zoomed, which is the metric used for testing WCAG 2.2 Success Criterion 1.4.10 Reflow (Level AA).
There are two key issues to note here:
- The header takes up around 60% of the viewport, leaving a very small area in which the actual page content can be viewed
- The header area itself does not scale, so only one of the five navigation items is visible, "Dashboard"
This could be improved through a better implementation of the sticky header. The broken navigation could be changed so that it converts to a 'hamburger' menu. The branding and padding could also be reduced to give everything else some more space. As the video below demonstrates, the sticky header takes up a small amount of space and the navigation is tucked away into a menu:
But even if this were better-implemented, the sticky header is still problematic as it still obscures some content and can make browsing with a keyboard difficult which affects people with low vision who don't use a mouse. The video demonstrates this issue:
For example, keyboard-only users scroll web pages using the SPACE key. By default, pressing SPACE scrolls the page down by one viewport height, which is an efficient way to read longer content.
When a sticky header is present, the browser does not account for its height when scrolling. Content is positioned underneath the header, partially hidden from view. People must then press the arrow keys to reposition the page before they can continue reading. At high zoom levels, where the viewport is already small, this repeated adjustment becomes slow and frustrating.
We explore this and workarounds in sticky content, focus obscured.
Design for equivalent functionality at all zoom levels
When zooming a page within the browser by 300% or 400%, it can trigger the mobile layout. If features have been removed in that layout, people lose access to them, even though they are still using a desktop device.
When creating a mobile view of a website, be mindful not to make the mistake of chopping out features that you think a mobile user might not need. Common examples may include:
- Print functionality: exposing a 'Print' button that launches a more printer-friendly view of the page
- Export as PDF/CSV/Excel: providing options to export data to a format typically used by a desktop application
Here's an example of a page that has both:
The bank statement above has Print and Export options in desktop view but when content is zoomed on a desktop, or viewed on a mobile screen, they are completely missing:
Here's the same statement in a desktop browser, with content zoomed to 300%. The functionality is provided in a pop-up menu instead of buttons permanently fixed above the transaction data:
In short, functionality available in a desktop view should not be removed in smaller viewports. It must remain available in every layout. The design may need to adapt to accommodate reduced screen space, but the capability itself should not disappear. What matters is providing a comparable experience, regardless of viewport size or zoom level.
Resources
- Web accessibility perspectives, clear layout and design - Web Accessibility Initiative
- Web accessibility perspectives, customisable text - Web Accessibility Initiative
- Guide to the Inclusive Design Principles
- Designing for users with low vision PDF - UK Home Office
Next steps
For more information about the Web Content Accessibility Guidelines, read our WCAG primer or find out more about how an assessment can help you identify issues in your websites, mobile applications, design systems, and other products and services.