Accessibility for Brand Sites
Brand sites often treat accessibility as an afterthought. Building it into the design process from the start produces better experiences for everyone.
Accessibility Is Not a Checkbox
There is a pattern we see repeatedly on brand-focused websites: the visual design gets locked in, the front-end gets built, and then someone asks about accessibility. At that point, remediation becomes a constrained exercise—bolting ARIA labels onto inaccessible patterns, adjusting colours that are baked into brand guidelines, and adding skip links to navigation structures that were never designed to be keyboard-navigable.
This backwards approach produces compliance at best and functional accessibility at worst. The fixes are technically present but experientially hollow. A screen reader can traverse the page, but the experience is incoherent because the page structure was designed for sighted mouse users and adapted after the fact.
The alternative is to treat accessibility as a foundational design constraint, on par with responsive behaviour and performance. When accessibility shapes decisions from the wireframe stage, the resulting interface is better for everyone—not just assistive technology users, but also people navigating on touchscreens, people using keyboards by preference, people on slow connections, and people in bright sunlight struggling with low contrast.
This article lays out the accessibility considerations that matter most for brand-oriented websites, drawing from real project decisions rather than abstract guidelines.
Colour and Contrast in Brand Contexts
Brand colour palettes are rarely designed with WCAG contrast ratios in mind. A brand might specify a light grey for body text on a white background because it looks elegant in Figma at 400% zoom. At actual rendering size on a standard display, that elegant grey becomes unreadable for a significant portion of the audience.
The tension between brand aesthetics and contrast requirements is real but often overstated. Most brand palettes can meet AA contrast standards with minor adjustments that are imperceptible in the overall design. A body text colour shifted from #999999 to #767676 on a white background crosses the 4.5:1 contrast threshold without visible impact on the brand's tonal character.
Where the challenge becomes genuine is with light-on-light and dark-on-dark treatments—thin text on muted backgrounds, placeholder text in form fields, disabled state indicators. These secondary text instances are often where contrast failures concentrate, and they are exactly the places where low-vision users need legibility most.
Our approach is to audit every text-background combination in the colour system during the design phase, not after handoff. We maintain a contrast matrix that maps every text colour to every background colour and flags combinations below threshold. As documented in the MDN Web Docs accessibility guidelines, WCAG provides specific ratio requirements for normal text, large text, and non-text elements. Catching violations early is cheaper and produces better outcomes than remediating them later.
Semantic Structure and Heading Hierarchy
Brand sites frequently sacrifice semantic HTML structure for visual styling flexibility. Designers spec a heading size that feels right visually, and developers implement it with whatever heading level produces that size, or worse, with styled paragraphs. The result is a heading hierarchy that makes visual sense but semantic nonsense.
Screen readers and other assistive technologies use heading structure to build a navigable outline of the page. When headings skip levels—jumping from H1 to H4 because the visual size happens to match the design—that outline becomes unusable. Users who navigate by heading (a primary strategy for screen reader users) encounter a confusing, broken map of the page.
The fix is simple in principle: design the visual heading scale to match the semantic heading hierarchy, using six distinct sizes that correspond to H1 through H6. In practice, most brand sites need only four levels (H1 through H4), which is manageable.
The heading hierarchy should be established in the design system, not negotiated per page. Every page template should have a documented heading structure that specifies which elements are H1 (one per page), which are H2 (major sections), and which are H3 (subsections). This documentation prevents the drift that occurs when different developers or content authors make independent heading choices.
Navigation and Keyboard Access
Navigation patterns on brand sites often prioritise visual elegance over keyboard accessibility. Mega-menus with hover triggers, hamburger menus with custom animation, and scroll-based navigation reveals are common patterns that work well with a mouse but fail entirely for keyboard users.
Every interactive element on the page must be reachable and operable via keyboard. This means logical tab order, visible focus indicators, proper ARIA roles for custom components, and escape-key support for modal and overlay patterns. These are not edge cases—they are baseline requirements.
Focus indicators deserve special attention on brand sites because the default browser focus ring is often the first thing designers want to remove. It conflicts with the visual aesthetic. Removing it without providing a custom alternative is an accessibility failure. The solution is to design a custom focus indicator that integrates with the brand's visual language: a subtle offset outline, a background highlight, or a border treatment that is visible without clashing with the design.
Skip links—those hidden-until-focused links that allow keyboard users to bypass repetitive navigation—should be standard on every page. They are trivial to implement and make a meaningful difference for users who navigate every page on the site via keyboard.
Image and Media Accessibility
Images on brand sites serve different functions, and each function has different accessibility requirements. Decorative images—background textures, divider graphics, purely aesthetic photographs—should be marked with empty alt text so screen readers skip them. Informative images—photographs that communicate content, diagrams, charts—need descriptive alt text that conveys the information the image provides.
The challenge for brand sites is that many images fall in a grey area. A hero photograph on a case study page might be primarily atmospheric, but it also communicates something about the project's visual character. The alt text decision requires editorial judgment: what would a non-sighted user need to know about this image to understand the page fully?
Our rule of thumb: if removing the image would leave a gap in the page's meaning, it needs informative alt text. If the page reads complete without it, the image is decorative and gets an empty alt attribute.
Video content presents additional challenges. Auto-playing video—common on brand homepages—must have accessible controls, including pause functionality, and should respect the user's motion preference settings. Captions are necessary for any video that includes speech, and audio descriptions are needed for video where visual content conveys information not available in the audio track.
Form Accessibility
Contact forms and enquiry forms are critical conversion points on brand sites, and they are frequently built with inaccessible patterns. Floating labels that disappear on focus, custom select dropdowns that do not announce options to screen readers, and validation messages that appear visually but are not associated with their fields through ARIA are common issues.
Every form field needs a visible label (not just a placeholder), a programmatic association between the label and the field, and clear error messaging that identifies both what went wrong and how to fix it. Error messages should be announced to screen readers when they appear, using ARIA live regions or by moving focus to the first error.
Custom form controls—styled checkboxes, toggle switches, date pickers—need to maintain the same keyboard interaction patterns as their native HTML equivalents. A custom checkbox must toggle with the Space key. A custom select must navigate with arrow keys. Users who rely on keyboard interaction have built muscle memory around these patterns. Breaking them creates confusion and frustration.
Testing and Ongoing Compliance
Automated accessibility testing catches roughly thirty to forty percent of accessibility issues. The rest require manual testing: keyboard navigation walkthroughs, screen reader testing with at least two reader and browser combinations, and content review for alt text quality and heading structure coherence.
We build accessibility testing into the development workflow rather than treating it as a pre-launch audit. Every component is keyboard-tested during development. Every template is screen-reader tested before content population. Every page is audited against WCAG criteria before it enters the review cycle.
This embedded approach costs less than remediation and produces better results. Accessibility fixes applied after the design is finalised are always compromises. Accessibility decisions made during design are integrated naturally.
Frequently Asked Questions
Does accessibility make brand sites look generic?
No. Accessibility constraints shape decisions but do not dictate aesthetics. A well-designed accessible site is indistinguishable from a well-designed site, period. The constraints are structural, not visual.
Which WCAG level should brand sites target?
AA is the standard target and meets legal requirements in most jurisdictions. AAA is aspirational and worth pursuing for individual criteria where feasible, but full AAA compliance is rarely practical for complex brand sites.
How do we handle brand fonts that have poor legibility at small sizes?
Set minimum size thresholds in the design system. If the brand font performs poorly below 14 pixels, do not use it below 14 pixels. Legibility is non-negotiable.