8. Design Systems, Styling and Accessible UX

Introduction and Context

A frontend application is experienced not as a collection of isolated screens but as a coherent visual, interactive and semantic environment. Users notice when buttons behave differently on different pages, when spacing changes unpredictably, when colour contrast is poor, or when a form cannot be completed with a keyboard. These problems are rarely caused by one defective component. They usually arise because an application lacks a shared design system and an intentional approach to accessibility.

In React and Angular development, design systems connect visual design, component engineering, content, accessibility and governance. They define how interfaces should look, behave and evolve. A design system may include design principles, colour and typography rules, design tokens, reusable components, documentation, testing conventions and contribution processes. Styling architecture provides the technical means to implement these decisions, while responsive design ensures that the interface remains usable across devices and conditions.

Accessible user experience extends this work beyond visual consistency. It asks whether people with different abilities, devices, languages, levels of digital literacy and environmental constraints can perceive, understand, navigate and operate the application. Accessibility is therefore not merely a compliance task performed before release. It is a quality attribute of the entire frontend architecture.

This chapter examines how professional teams create reusable design systems with React or Angular, organise CSS, build responsive interfaces, apply WCAG principles, implement semantic HTML and keyboard interaction, and support internationalisation and inclusive design. The focus is not on a particular library but on the reasoning required to make design and implementation decisions responsibly.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the purpose, structure and governance of a frontend design system.

2. Distinguish design tokens, components, patterns, templates and product-specific features.

3. Select suitable styling architectures for React and Angular applications.

4. Apply responsive, fluid and content-aware layout techniques.

5. Use semantic HTML, accessible names, keyboard interaction and focus management correctly.

6. Relate practical frontend decisions to the WCAG principles of perceivable, operable, understandable and robust design.

7. Design interfaces that support internationalisation, localisation and inclusive use.

8. Evaluate design-system trade-offs, risks and maintenance practices in professional projects.

From Visual Consistency to a Governed Design System

A style guide records visual rules; a component library supplies reusable implementation; a design system is broader than either. It is a shared system of decisions, assets, code and working practices that enables teams to build consistent experiences efficiently. The system should answer questions such as: Which button variant is appropriate for a destructive action? How is an error conveyed to a screen-reader user? What spacing scale is permitted? Who approves a new component?

A useful model has several layers. The foundation layer contains colour roles, typography, spacing, sizing, elevation, borders, motion and iconography. The component layer contains controls such as buttons, inputs, dialogs, tabs and navigation elements. The pattern layer combines components into recurring solutions such as search forms, filter panels and authentication flows. Templates describe page-level arrangements, while product features apply these resources to a particular domain.

This separation prevents two opposite failures. If every product team invents its own patterns, the user encounters inconsistency and the organisation accumulates expensive maintenance. If the system attempts to prescribe every page, it becomes rigid and obstructs legitimate product needs. A mature system defines constraints where consistency reduces cognitive load, while allowing deliberate variation where context requires it.

Design Tokens as the System’s Vocabulary

Design tokens are named values representing design decisions. Instead of scattering a literal colour such as `#005fcc` throughout stylesheets, a team might define a semantic token such as `--color-action-primary`. Tokens can represent colour, spacing, font size, line height, border radius, shadow, animation duration and breakpoint behaviour.

Tokens should normally be semantic rather than tied only to appearance. `--color-surface-danger` communicates purpose more effectively than `--red-600`. This distinction allows a theme, high-contrast mode or dark mode to change the underlying value without requiring every component to be rewritten. A token taxonomy often includes:

• Primitive tokens, which describe raw values such as a hue or base spacing unit.
• Semantic tokens, which express roles such as action, surface, border, focus or error.
• Component tokens, which describe a local decision such as a button’s padding or a dialog’s maximum width.

Tokens may be stored in a technology-neutral format and transformed into CSS custom properties, JavaScript or TypeScript constants, Android resources and design-tool variables. The transformation process should preserve naming, documentation and accessibility intent. A token pipeline is valuable only if the generated outputs remain understandable and versioned.

Components, Contracts and Composition

A reusable component is not simply a visual fragment. It has a contract: accepted properties or inputs, emitted events, states, semantic structure, keyboard behaviour, responsive behaviour and accessibility requirements. For example, an accessible button component must distinguish its native button behaviour from a link, expose a disabled or busy state appropriately, and provide a visible focus indicator.

React commonly expresses component contracts through props, composition and controlled or uncontrolled state. Angular uses components, inputs, outputs, content projection and services. In both ecosystems, a component should expose meaningful configuration rather than a large collection of styling escape hatches. Excessive props often indicate that the component is attempting to solve several unrelated problems.

A component library should document normal, hover, focus, active, disabled, loading, empty, error and long-content states. Storybook or an equivalent workbench can make these states visible, but documentation is not a substitute for automated and manual testing. Components must be tested in context because composition can introduce problems that are invisible in isolation.

Choosing a Styling Architecture

Styling architecture determines how rules are authored, scoped, composed and maintained. There is no universally correct choice; the suitable approach depends on team size, framework conventions, performance requirements, legacy constraints and the expected rate of visual change.

Global CSS with a disciplined naming convention can be simple and efficient. Methodologies such as BEM separate blocks, elements and modifiers, reducing accidental collisions. Utility-first CSS offers small, composable classes and can make spacing and responsive rules explicit in markup. CSS Modules provide locally scoped class names, while CSS-in-JS places style definitions near components and may support dynamic values. Angular supports component style encapsulation modes, including emulated encapsulation, while React projects often combine CSS Modules, utility frameworks or plain stylesheets.

Each approach has trade-offs. Global styles are easy to inspect but require rigorous naming and dependency control. Utility classes reduce custom CSS but can make markup dense and may encourage one-off values. CSS-in-JS can express component state conveniently but may introduce runtime or tooling complexity. Encapsulation prevents leakage but can complicate global theming, third-party integration and debugging.

A robust architecture usually establishes:

1. A small set of global foundations, including reset or normalisation, font loading, token declarations and base document styles.

2. Component-level styles that do not depend on undocumented selectors inside other components.

3. Explicit state classes or attributes rather than selectors based on DOM position.

4. A layering strategy, such as CSS cascade layers, for reset, tokens, components, utilities and overrides.

5. Rules for when a local exception is acceptable and how it is documented.

The principle is to make dependencies visible. A component should not break merely because another component changes its internal markup or because a page happens to contain a particular ancestor class.

Responsive Design as Adaptation, Not Shrinkage

Responsive design is the adaptation of layout, content and interaction to available conditions. It is not the practice of reducing a desktop page until it fits a mobile viewport. A responsive interface may change column structure, navigation, information density, control size, typography, image treatment and reading order.

The most reliable approach is content-first. Breakpoints should be introduced when the content or interaction begins to fail, rather than selected only from a list of device dimensions. CSS Grid is effective for two-dimensional page structures, while Flexbox is suited to one-dimensional alignment. Container queries allow a component to respond to the width of its containing region rather than the viewport, which is particularly valuable in dashboards and reusable cards.

Fluid techniques reduce unnecessary breakpoint rules. `clamp()` can create a value with minimum, preferred and maximum limits; relative units can support zoom and user preferences; intrinsic sizing can allow content to determine dimensions. However, fluidity must not produce unreadable line lengths, clipped content or controls too small for comfortable interaction.

Responsive design also includes behaviour. A wide table may become horizontally scrollable, a sidebar may become a disclosure panel, and a multi-column form may become a single-column sequence. These transformations must preserve meaning and keyboard order. Hiding information solely through CSS can create inconsistent experiences if the content remains present for assistive technologies or becomes inaccessible to keyboard users.

Accessibility Through the WCAG Lens

The Web Content Accessibility Guidelines organise accessibility around four principles: content must be perceivable, operable, understandable and robust. These principles are supported by testable success criteria at different conformance levels. WCAG is an important reference, but conformance statements do not replace user research or testing with disabled users.

Perceivable Interfaces

Information should not rely on colour alone. An error field might use colour, an icon, an error message and an appropriate relationship to the input. Images require alternative text according to their purpose: informative images need concise descriptions, decorative images generally need empty alternative text, and complex diagrams may require a longer explanation.

Text and interactive controls need sufficient contrast, but contrast is only one aspect of perception. Text should remain usable when enlarged, content should reflow without loss of information, and focus indicators should be visible. Motion should be purposeful and respect reduced-motion preferences. Audio and video may require captions, transcripts or other alternatives.

Operable Interaction

All functionality should be available from a keyboard, and the focus order should follow a meaningful sequence. Native HTML controls provide extensive behaviour at little cost. A `button` is preferable to a clickable `div`; a link is preferable when the action changes location. If a custom widget is necessary, its keyboard model must be deliberately implemented and documented.

Focus management becomes especially important in single-page applications. When a route changes, the application should place focus at a meaningful location, such as the main heading or a route-status region, without disorienting the user. Opening a modal requires moving focus into the dialog, preventing inappropriate interaction with the background, and returning focus to the invoking control when the dialog closes.

Understandable Experiences

Labels, instructions and error messages should use clear language. Validation should identify the affected field and explain how to correct it. Persistent navigation and naming conventions should remain consistent. Forms should preserve entered data where possible and should not impose unnecessary time limits.

Internationalisation is closely related to understandability. Text should be externalised rather than concatenated in code, plural rules should be handled through locale-aware APIs, dates and numbers should be formatted according to locale, and layouts should tolerate text expansion. Right-to-left languages may require logical CSS properties such as `margin-inline-start` instead of physical left and right declarations.

Robust Implementation

Robustness means that content and controls can be interpreted reliably by browsers, assistive technologies and future user agents. Correct HTML semantics provide a strong foundation. ARIA can supplement HTML, but it should not replace native elements when native semantics are available. An incorrect ARIA role can create a misleading accessibility tree and is often worse than no custom role.

Accessible names are central. A button containing only an icon needs a programmatic name, normally through visible text, an associated label or an appropriate attribute. Form controls need labels, and groups of related controls may need a fieldset and legend. Relationships such as description, error and expanded state must be exposed in a way assistive technologies can interpret.

Semantic HTML and Keyboard Interaction in Framework Applications

Framework templates can tempt developers to treat the DOM as an implementation detail. It is not. The DOM is the interface through which browsers, search engines, accessibility APIs and automation tools understand the application. Headings should represent document structure, lists should represent lists, tables should represent tabular relationships, and landmarks such as `main`, `nav` and `footer` should be used meaningfully.

A common error is to use a clickable `div` because it is visually easy to style. Adding `role="button"` does not automatically add keyboard activation, focus behaviour or expected event handling. If the element is truly a button, use `<button>`. Framework event binding can then work with native keyboard and browser behaviour.

Custom widgets such as comboboxes, tabs, menus and tree views require more care. Their interaction patterns should follow established accessibility practices: arrow-key movement where appropriate, clear selected or expanded states, predictable tab stops and proper announcements. A tab interface, for example, should expose the selected tab, associate each tab with its panel and define sensible arrow-key behaviour. Developers should avoid inventing keyboard interactions that conflict with browser or assistive-technology expectations.

Focus styling must remain visible and should not be removed with `outline: none` unless it is replaced by an equally clear indicator. The `:focus-visible` pseudo-class can help distinguish keyboard focus from pointer interaction. Skip links allow keyboard users to bypass repeated navigation. For dynamic updates, a carefully scoped live region can announce status changes such as successful saving, but excessive announcements create noise.

Internationalisation and Inclusive Design

Internationalisation, or i18n, prepares a product for multiple languages and cultural conventions; localisation adapts it to a particular locale. These concerns should influence architecture from the beginning. A layout that works only for short English labels may fail in German, Arabic or a language using a different script.

Avoid embedding text in images, assuming one plural form, constructing sentences by concatenating fragments, or using flags as a proxy for language selection. Translation keys should describe meaning rather than current wording. Message-formatting tools should support pluralisation, gender where linguistically necessary and variable interpolation safely.

Inclusive design goes beyond disability categories. It considers temporary and situational limitations, such as a broken arm, glare, slow connectivity, noisy surroundings or one-handed mobile use. It also recognises differences in age, culture, literacy, economic access and device capability. Helpful practices include readable language, forgiving validation, scalable text, resilient network states, sufficient target size, reduced motion and clear recovery paths.

Design systems should encode inclusion rather than leaving it to individual developers. For example, a form component can require a visible label, reserve space for validation feedback, expose described-by relationships and support long translated strings by default.

A Practical Delivery and Governance Model

A design system succeeds when its operating model is as clear as its code. A cross-functional group may include designers, frontend engineers, accessibility specialists, content designers, researchers and product representatives. Its responsibilities include defining contribution standards, reviewing changes, managing releases and resolving competing product needs.

A practical workflow begins with discovery of recurring problems rather than immediate component creation. The team then defines the interaction and accessibility contract, designs states and variants, implements the component, documents usage and tests it in realistic compositions. New variants should be justified by a distinct semantic or interaction need; cosmetic differences should normally be handled through tokens or themes.

Versioning is important because a shared component can affect many applications. Changes should be classified as additive, behavioural, visual or breaking. Deprecation guidance, migration examples and changelogs reduce organisational risk. Visual regression testing can identify unintended changes, while unit and integration tests verify state and interaction. Automated accessibility tools are valuable for detecting missing labels, invalid relationships and some contrast problems, but they cannot determine whether a heading structure is meaningful or whether a workflow is understandable.

Governance must avoid becoming bureaucracy. Contribution should be possible for product teams, but acceptance criteria should be explicit. A component that does not meet keyboard, semantic, responsive and documentation requirements should not be promoted as a shared standard.

Applied Case: Modernising a Public-Service Application

Background

This illustrative case concerns CivicConnect, a fictional public-service portal maintained by several teams using Angular. The portal allows residents to apply for permits, upload documents and track requests. Its original interface had grown through independent projects.

Situation and Problem

Users encountered different button styles, inconsistent error messages and forms that became unusable on small screens. Keyboard users could not reliably identify focus, and a modal document viewer trapped focus incorrectly. Translated labels overflowed cards, while a colour-only status system was difficult to interpret. Each team maintained its own SCSS variables and duplicated components.

Analysis

An audit showed that the principal problem was not a lack of visual polish but the absence of shared contracts. The teams had no common semantic colour roles, no agreed keyboard patterns and no ownership model. Some defects were architectural: route transitions did not provide a meaningful focus destination, and validation messages were visually adjacent but not programmatically associated with their fields.

Approach and Solution

The organisation first catalogued repeated patterns and prioritised high-risk components: buttons, form fields, alerts, dialogs, navigation and status indicators. It defined primitive and semantic tokens, then generated CSS custom properties for the Angular applications. Component contracts specified labels, error relationships, focus behaviour, responsive rules and translated-content expectations.

The form-field component required an associated label and generated stable identifiers for descriptions and errors. Status indicators combined text and iconography rather than colour alone. The dialog implementation moved focus to the first meaningful control, prevented background interaction, handled Escape appropriately and restored focus on close. A route-level service placed focus on the main heading after navigation when no more specific destination was available.

The team introduced a component workbench with long labels, high zoom, keyboard-only flows, reduced-motion settings and right-to-left previews. Automated checks ran in continuous integration, while manual reviews covered screen readers and realistic task completion. Product teams could request extensions through a documented contribution process.

Outcome

The portal achieved a more consistent interaction model and reduced duplicated styling. More importantly, accessibility became part of component acceptance rather than a late audit. Teams still retained freedom to design domain-specific workflows, but they no longer had to reinvent basic controls and patterns.

Learning Points

The case demonstrates that design systems are socio-technical systems. Tokens alone cannot solve inconsistent behaviour; governance alone cannot repair poor semantics. The strongest results came from combining shared implementation, explicit accessibility contracts, testing evidence and a process for controlled evolution.

Risks, Limitations and Common Mistakes

A design system can become a bottleneck if its maintainers reject legitimate needs or release changes too slowly. It can also become a superficial brand layer if it standardises colours and spacing while ignoring keyboard behaviour and content design. Excessive abstraction is another risk: a universal component with dozens of flags may be harder to use than a small set of focused components.

Common technical mistakes include overriding focus indicators, using placeholder text as a label, relying on colour to communicate state, setting fixed heights that clip translated content, hiding content with inappropriate CSS, and placing interactive elements inside one another. Developers also sometimes test only a component’s default state, neglecting loading, error, disabled, zoomed and long-content conditions.

Accessibility overlays and automated scanning services should not be treated as substitutes for accessible engineering. They may mask symptoms, introduce new interaction problems or create false confidence. Likewise, visual regression tools can confirm that a page changed, but they cannot decide whether the new design is clearer or more inclusive.

Professional and Ethical Considerations

Accessibility has legal and organisational implications, but its ethical basis is equally important. Excluding people from essential services because a team did not budget for keyboard testing is a design failure, not merely a technical defect. Teams should identify accessibility risks early, allocate ownership and include affected users in research where possible.

Privacy also matters. Assistive technology testing, analytics and personalisation should not require unnecessary collection of sensitive information. Telemetry must be proportionate, transparent and governed. Design tokens and component libraries should be versioned and maintained like other critical infrastructure because silent changes can affect many users and organisations.

Emerging Directions

Current frontend practice is moving toward token standards that can serve design tools and multiple platforms, container-query-based responsiveness, improved colour-scheme support and more systematic component documentation. Native browser capabilities increasingly reduce the need for JavaScript in tasks such as dialogs, popovers and form controls, although support and accessibility behaviour must still be verified in target environments.

AI-assisted coding and design tools can accelerate component generation, token migration and test creation. They can also reproduce inaccessible patterns at scale, invent unsupported ARIA behaviour or expose confidential source material. AI output therefore requires expert review against semantic, security, localisation and accessibility requirements. The emerging professional skill is not merely generating code quickly but evaluating whether generated code preserves the design system’s contract.

Best-Practice Checklist

A production design system should use semantic tokens, native HTML where possible, documented component states and a controlled contribution process. It should test keyboard operation, focus visibility, zoom, responsive reflow, translated content, reduced motion and screen-reader interpretation. React and Angular implementations should keep styling dependencies explicit and avoid coupling components to fragile DOM structures.

Teams should introduce accessibility at design and component-definition stages, not after page completion. They should combine automated testing, code review, visual comparison, manual keyboard testing and task-based evaluation with users. Finally, they should measure the system by outcomes: reduced inconsistency, faster safe delivery, fewer recurring defects and better completion of real user tasks.

Chapter Summary

A design system is a governed set of design decisions, tokens, components, patterns, documentation and practices. Its purpose is to support consistency without eliminating contextual judgement. Design tokens provide a shared vocabulary; component contracts define behaviour, states and accessibility; styling architectures control scope and maintainability; and responsive techniques adapt interfaces to content and conditions.

Accessible UX depends on semantic HTML, visible focus, keyboard operation, appropriate names and relationships, meaningful feedback, robust responsive layouts and support for internationalisation. WCAG’s principles of perceivable, operable, understandable and robust design provide a useful framework, but accessibility also requires manual testing, user involvement and organisational accountability. In React and Angular applications, reusable implementation is valuable only when it preserves inclusive interaction. Effective governance, versioning and evidence-based testing allow a design system to evolve without becoming either chaotic or restrictive.

Key Terms

Design system: A governed collection of design principles, tokens, components, patterns, documentation and practices.

Design token: A named representation of a reusable design decision such as colour, spacing or typography.

Semantic token: A token named according to its purpose or role rather than only its visual value.

Component contract: The documented inputs, outputs, states, structure, behaviour and accessibility expectations of a component.

Component library: A coded collection of reusable interface components.

Pattern: A recurring combination of components used to solve a broader interaction problem.

CSS architecture: The conventions and structures used to organise, scope and maintain styles.

CSS custom property: A browser-supported variable declared in CSS and resolved at runtime.

Responsive design: The adaptation of layout and interaction to viewport, container, content and user conditions.

Container query: A CSS mechanism that allows styles to respond to a containing element’s size.

Semantic HTML: HTML elements selected according to their meaning and intended function.

Accessible name: The programmatically available name by which an assistive technology identifies a control.

Focus management: Deliberate control of keyboard focus during navigation, dialogs and dynamic updates.

WCAG: Web Content Accessibility Guidelines for making web content accessible.

Internationalisation: Designing software so it can support different languages, locales and cultural conventions.

Localisation: Adapting software content and presentation for a particular locale.

Inclusive design: Designing for a broad range of abilities, identities, contexts and limitations.

Live region: A region whose dynamic changes may be announced by assistive technologies.

Visual regression testing: Comparing rendered interfaces to detect unintended visual changes.

Progressive enhancement: Building a functional baseline and adding advanced capabilities where supported.

Review Questions

Short Answer Questions

1. What distinguishes a design system from a component library?

2. Explain the difference between primitive, semantic and component tokens.

3. Why is a native button generally preferable to a clickable `div`?

4. What is the purpose of focus management after a single-page application route change?

5. Distinguish internationalisation from localisation.

Long Answer Questions

1. Explain how design tokens, component contracts and governance work together in a scalable design system.

2. Compare global CSS, utility-first CSS, CSS Modules and CSS-in-JS, including their principal trade-offs.

3. Discuss the four WCAG principles and relate each to practical frontend decisions.

4. Describe how a responsive form component should accommodate different screen sizes, zoom levels and translated content.

5. Explain why automated accessibility testing is necessary but insufficient for establishing an accessible user experience.

Analytical / Application Questions

1. A React application uses colour alone to distinguish successful, pending and failed transactions. Propose a design-system solution that improves perception, semantics and screen-reader communication.

2. An Angular modal works with a mouse but allows keyboard focus to move behind it. Analyse the defect and specify the required focus and background-interaction behaviour.

3. A shared card component clips long German labels and becomes confusing in a right-to-left locale. Recommend token, CSS, content and testing changes that would make the component resilient.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes a design system?

A. A collection of brand colours used by a design team

B. A governed system of design decisions, reusable implementation, documentation and practices

C. A stylesheet containing only responsive media queries

D. A page template that cannot be changed by product teams

Correct Answer: B. A governed system of design decisions, reusable implementation, documentation and practices

Question 2

Why are semantic tokens generally more adaptable than tokens named only by colour?

A. They eliminate the need for CSS

B. They allow a role such as action or error to change value across themes without changing component intent

C. They automatically provide keyboard support

D. They guarantee compliance with every WCAG criterion

Correct Answer: B. They allow a role such as action or error to change value across themes without changing component intent

Question 3

Which implementation is normally the most appropriate for an action that submits a form?

A. A clickable div with a mouse event

B. A span with a button role but no keyboard handler

C. A native button element

D. An image with alternative text

Correct Answer: C. A native button element

Question 4

What is the primary purpose of moving focus into a modal when it opens?

A. To increase the modal’s visual contrast

B. To prevent keyboard users from interacting unpredictably with background content

C. To make the modal load faster

D. To remove the need for a close control

Correct Answer: B. To prevent keyboard users from interacting unpredictably with background content

Question 5

Which practice best supports internationalisation?

A. Concatenating translated sentence fragments in code

B. Using images containing English labels

C. Externalising messages and using locale-aware plural, date and number formatting

D. Setting fixed heights for all text containers

Correct Answer: C. Externalising messages and using locale-aware plural, date and number formatting

Question 6

A status indicator is distinguished only by red, yellow and green colours. What is the most important improvement?

A. Use smaller colour swatches

B. Add text or other non-colour information that communicates each status

C. Remove the status indicator entirely

D. Use more saturated colours only

Correct Answer: B. Add text or other non-colour information that communicates each status

Question 7

Which technique allows a reusable component to respond to the width of its containing region rather than the viewport?

A. A container query

B. A global reset

C. A live region

D. A semantic token

Correct Answer: A. A container query

Question 8

Which statement about automated accessibility tools is most accurate?

A. They can replace manual keyboard and user testing

B. They detect every accessibility problem if the page has valid HTML

C. They identify some classes of defects but cannot fully judge meaning, workflow or usability

D. They are useful only for visual regression testing

Correct Answer: C. They identify some classes of defects but cannot fully judge meaning, workflow or usability

Question 9

In a single-page application, what is a suitable response after a route change?

A. Remove all focus indicators

B. Place focus at a meaningful destination, such as the main heading, when appropriate

C. Force focus to the browser address bar

D. Reload the page after every navigation

Correct Answer: B. Place focus at a meaningful destination, such as the main heading, when appropriate

Question 10

Which governance decision best reduces risk when changing a shared component?

A. Change its behaviour without documentation to preserve speed

B. Allow every team to maintain a private incompatible version

C. Classify the change, version it appropriately and provide migration guidance for breaking changes

D. Prevent all future changes to the component

Correct Answer: C. Classify the change, version it appropriately and provide migration guidance for breaking changes