Prologue
A while ago, I decided to develop a fully accessible main navigation component in React.
While a preliminary set of requirements has been assembled for the component itself, design requirements still need to be considered.
Most WCAG requirements regarding visual perceivability affect CSS and, by extension, design. If a design prototype in a system like Figma does not meet those visual requirements, it doesn't matter how clean the component code is; the visual aspect will not be accessible. This article considers design requirements, especially those related to WCAG success criterion 1.4.4, Resizing Text.
As I've mentioned before, development isn't the only engineering area where accessibility has to be considered. Whether it's a functional prototype in a tool such as Figma, or implementing the CSS from such a design, there are several success criteria from the Web Content Accessibility Guidelines that must be met, and so those criteria are pulled into the requirements matrix.
Unlike a developer who only needs to be aware of and develop the peripherals associated with perception (screen and screen reader) and operability (pointer and keyboard), team members responsible for the design and styling of a website, regardless of the tools they use, need to be conscious of both neurodiversity and variations of visual impairment.
Neurodiversity requires care when designing the overall site and pages to reduce sensory overload, shorten blocks of text, and maintain high color contrast. Keeping layouts and navigation consistent also enables these users to navigate a website or page effectively.
A user's vision may be corrected with visual aids, such as glasses, or other assistive technology, or it may not. Users may be able to identify the colors chosen, or they may not. Some users may experience difficulties with small text or low contrast and need support, particularly as they age. The Web Content Accessibility Guidelines (WCAG) requirements for vision are intended to support users who experience these issues. Other requirements, while still visual, are intended to support keyboard focus or to enable adequate targeting of interactive objects.
I want to group the requirements around sizing, as detailed in the requirements matrix, and discuss them.
Design Requirements
- Text should be able to be resized without assistive technology up to 200 percent without the loss of content or functionality. WCAG 1.4.4 Resize Text (A).
Not every user can assimilate small text. Current recommendations are that most text on your page should have a font size of at least 16 pixels. Care should be taken to ensure not only that text can be enlarged, but also that, when a user enlarges a page, everything on it remains proportional regardless of the browser's font size.
- Ensure no loss of content or functionality occurs when text spacing properties are set to specific values—WCAG 1.4.12 Text Spacing (AA).
Contrary to popular opinion, not every user will see your design the way you intended. Users can create their own stylesheets and override your styles. These should be implementable without breaking your entire site. Text spacing properties include the CSS properties line-height, letter-spacing, and word-spacing, along with the margins between paragraphs.
- Any keyboard operation should make a focus indicator visible. WCAG 2.4.7 Focus Visible (AA).
When using a keyboard, the focus-visible pseudo-class is triggered as focus shifts to a focusable element, allowing a user to visually identify which element has focus. Styling should be applied, either globally or to a specific element, to help screen and keyboard users know where focus is on the screen.
- The size of the target for pointer inputs should be at least 24 x 24 pixels or should have padding around it to conform to a spacing of 24 x 24 pixels between it and any other pointer input—(WCAG 2.5.8 Target Size (Minimum) (A)](https://www.w3.org/WAI/WCAG22/quickref/#target-size-minimum).
People don't have a fixed finger size. Small target areas are difficult for people with larger fingers or those with shaky hands, especially when targets overlap. Creating sufficient spacing between interactive elements ensures the intended target is actually triggered.
Although it isn't specifically mentioned in the WCAG guidelines, there should also be visual indications when an element is hovered over. Focus is for keyboards, hover is for pointers. In many cases, focus and hover states should be similar, if not identical, after all, they convey the same message.
All of these requirements can be implemented through a theming system. A well-designed theming system can automatically apply many of these accessibility features. Conversely, a poorly thought-out theming system can make styling harder to implement and break the accessibility of your screen display.
The repository I created for this series contains a slimmed-down version of the theming system I'm building. The theming system is built on standard CSS, defining colors and spacing and integrates with foundational components to support a default theme.
Theming systems should integrate with browser settings to enable automatic adjustments aligned with specific accessibility features, such as dark mode or font customization, especially sizing.
When using Zoom controls (Ctrl+/Ctrl-) to enlarge a page, every browser simply increases the pixel size. Actual font sizes are not affected. But what happens when the underlying font size itself changes?
Every browser sets a font size, which can be defined as 1rem (root em). Every browser sets the default font size to 16px. Almost every corporate and government website uses a design that assumes the font size is set to 16 pixels.
Why 16 pixels? As a geometric progression, the doubling of numbers: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 is a consistent progression within both computer hardware and software. Screens are designed to have pixel sizes evenly divisible by these numbers. The progression, though not a true Fibonacci sequence, is aesthetically pleasing and has become a de facto industry standard.
When a user changes the default font size, the 1rem unit also scales. Instead of 1rem being equivalent to 16 pixels, 1rem can be returned as a different number of pixels, depending on the browser's font-size setting.
Every browser has a setting to adjust the default font size. Chrome and Edge use a "small, medium, large" basic setting while also allowing more granular changes to font face and size. Firefox lets you choose the default font size, while Safari only lets you restrict the smallest font size. Realistically, there's no way to determine how many pixels actually make up 1rem on a user's browser.
I'm sure this realization comes as a surprise to many people, especially designers, and it can and does cause issues when a design or theming system doesn't account for a possible change in rem units.
Change the font size while browsing your site and see how it fares:
- Chrome: Settings -> Appearance -> Font size
- FireFox: Settings -> Language and Appearance -> Fonts
- Edge: Settings -> Appearance -> Fonts -> Font Size
- Safari: Settings -> Advanced -> Never use font sizes smaller than [select size]
The Sam's Club homepage is an example of what happens when the default font size changes and the application doesn't account for it. I increased the font size in Chrome to "very large," which set the rem value to 24px. The website mixes px and rem, which contributes to the issue.
[Screenshot of the Sam's Club home page using the default browser font size of 16px]
[Screenshot of the Sam's Club home page with the browser font size set to "very large" (24px)]
Notice the obvious changes in the header and the tags just below. Vertical spacing is no longer centered, and the dollar amount is obscured because it now sits on top of the bottom wheels, forming the cart icon.
Suddenly, a design is being driven by incorrect pixel values. After all, 0.5rem off a 24 pixel base font is 12px, not 8, and .25rem is 6px, not 4. Carefully designed ratios and proportions can and will be thrown off.
Having a user adjust the browser font size shouldn't disrupt your design, but when the system isn't designed for proportional scaling, the results are obvious and unprofessional.
Take your own site for a spin, reset the browser font size and see what happens. I'll wait.
Designing for user-defined font sizes is possible without sacrificing the base-16 design assumptions. Theming systems can accommodate this by standardizing the relative pixel value to 1/16 of a rem, regardless of the actual rem value.
@layer system {
:root {
--sizing-base: 1rem;
--sp-px: calc(var(--sizing-base) * 0.0625);
}}
I use the —sp namespace to ensure no other variable can override my choice, and a relative px is 1/16th of the browser's font size. Everything, depending on placement — padding, font-size, width, or positioning — uses calc(var(--sp-px) * #), where # is the number of pixels. This guarantees that the ratio and proportions remain consistent regardless of the user's chosen font size.
CSS cascade layers solve an issue with specificity by allowing themes to set layers of specificity and the order in which styles can be overridden. In this case, the system layer is near the bottom of the layers I've defined for my site, '@layer reset, system, default-theme, base-component, common-component, system-component, main;`; meaning it will be applied early in the process.
The more thought and functionality the theming system receives, the easier it will be to implement accessibility across design and development for designers and developers. As an added bonus, appearance can be guaranteed to be consistent and usable.
Next Steps
Before a clickable prototype can be created, base components must be created and updated, and their styles need to be tied to the theming system. The requirements for these components can be found in the accessibility requirements.
I'll be covering this in the next article.
Top comments (0)