DEV Community: Andrew Arhangelski

Building an Accessible Front End: A Journey Towards Inclusive Web Design

Andrew Arhangelski — Fri, 06 Dec 2024 17:07:05 +0000

Creating an accessible front end is not just about meeting legal requirements or checking off boxes; it's about making sure every user can fully engage with and enjoy our applications. Accessibility empowers individuals with diverse needs, whether they’re navigating via screen readers, keyboards, or assistive devices. Here’s a deeper dive into our journey and approach to embedding accessibility in every phase of front-end development.

Accessibility Starts with Design

Accessibility isn’t an afterthought—it begins at the design stage, where choices around fonts, colors, and layout have a profound impact on usability. Often, there’s a temptation to make text subtle and “blend in,” like 4 pt light gray text on a white background. This might create a clean, minimal look, but it also risks making content unreadable, especially for those with visual impairments or color blindness.

By prioritizing high-contrast text, readable font sizes, and a clear visual hierarchy, we make content accessible from the start. Designers are encouraged to think beyond aesthetics and ask: How will this be perceived by someone with low vision? Can everyone read and understand this content, regardless of their abilities?

Structure is Fundamental

A well-structured webpage doesn’t just benefit screen reader users; it helps everyone. Whether it’s someone navigating a webpage for the first time, a visually impaired person using a screen reader, or a user relying on keyboard navigation, proper structure offers clarity. Using semantic HTML elements like <header>, <main>, <section>, and <footer> helps convey content relationships, ensuring users understand the flow of information.

To illustrate, think of a structured webpage as resembling an old newspaper or a scientific document. Each section has headings, main text, and subheadings to guide readers through the information. When done right, even if we strip away all styling, the structure should still convey the page’s hierarchy, allowing users to understand and navigate content intuitively.

Consistent HTML Flow and Responsive Design

Today, we access content on screens of all sizes—desktop monitors, laptops, tablets, and phones. Responsive design ensures our applications look good across devices, but it’s also a core part of accessibility. A consistent HTML flow, from top to bottom and left to right, guarantees that users can navigate predictably, regardless of screen size.

We design our pages to adapt fluidly, so users experience a logical layout that’s easy to follow, even when the screen size changes. This predictability ensures that all users, whether they’re on a smartphone or a desktop, have a consistent and accessible experience.

Logical Heading Hierarchy

Clear heading structure enhances accessibility by helping users and assistive technologies like screen readers interpret page organization. By using a single <h1> tag for the main page heading and organizing subheadings in a logical order (<h2>, <h3>, etc.), we create a hierarchy that screen readers and search engines alike can understand.

This structure enables screen reader users to navigate quickly between sections, skipping to content they’re most interested in. It’s a simple yet powerful way to make our applications easier to use and understand. Well-structured headings are a roadmap for the content, guiding users intuitively.

Keyboard Accessibility: The Backbone of Interaction

Keyboard navigation is one of the most important facets of accessibility, allowing users to perform every task on a webpage without needing a mouse. For individuals with motor impairments or those who rely on screen readers, this isn’t optional—it’s essential.

We design our interfaces so users can select options, toggle buttons, close modals, and interact with every element via the keyboard alone. Keyboard navigation can solve up to 80% of accessibility issues, as it ensures that every element on the page is accessible. This simple step brings us closer to a fully inclusive web experience, benefiting all users.

Visible Focus States: Essential for Orientation

A visible focus indicator is a critical part of keyboard accessibility, showing users where they are on the page at any given moment. In the past, there were trends to hide focus outlines, as they were seen as unattractive. However, this outline serves as a “cursor” for keyboard and screen reader users, providing orientation as they tab through interactive elements.

Without a visible focus state, users can easily become disoriented and frustrated. By embracing this accessibility feature, we ensure that all users can confidently navigate through our application, knowing exactly where they are in the interface.

The Role of Invisible Markup: Enhancing Semantic Clarity

Invisible markup is all about using semantic HTML and ARIA attributes to enhance the experience for screen reader users. It’s more than just adding alt attributes or using <button> tags — it’s about making sure the web page structure is clear to assistive technologies.

For example:

Sections should be linked to headers, creating a logical flow for screen readers.
Tooltips should be connected to the relevant button or icon, so users have context.
Lists should be marked as <ul> or <ol> lists, even if they’re just styled to look like something else.
Tables should use proper <table> tags, with <th> and <td> cells defined, so screen readers can convey table information accurately.
Invisible markup, such as ARIA roles, labels, and landmarks, enables assistive technologies to navigate a page seamlessly, providing valuable context for users. This invisible layer of structure makes a profound difference in how content is experienced by those who rely on screen readers.

Testing with Screen Readers

Testing with screen readers is essential to truly understand the user experience of visually impaired individuals. On a Mac, VoiceOver provides built-in functionality to simulate this experience. By navigating using VoiceOver, we can observe how the application communicates structure and content to the user.

When testing, we can:

Navigate landmarks to quickly reach different sections, such as headers or footers.
Explore the hierarchy by tabbing through headings to observe how they guide users.
Navigate tables by moving through cells, ensuring the data makes sense sequentially.

Using a screen reader emphasizes the importance of accessible design decisions, from proper HTML structure to clearly linked elements. This hands-on testing is a valuable part of our accessibility toolkit, allowing us to see our work through the lens of users with different abilities.

Accessibility is a Continuous Journey

Accessibility isn’t a destination—it’s an ongoing commitment. By embedding these practices into our design and development process, we’re working to make the web a more inclusive space where everyone can participate fully. From initial design choices to development best practices and thorough testing, each step brings us closer to a universally accessible web.

Let’s keep pushing forward, designing, developing, and testing with accessibility as a priority. Together, we can build digital experiences that are truly inclusive and welcoming to all.

Illustrations were designed by Freepik www.freepik.com

Running Enzyme Tests in React 18: Our Success Story.

Andrew Arhangelski — Sun, 27 Oct 2024 23:57:25 +0000

Like many other companies with mature software, we found ourselves at a crossroads with our React application. The app, initially developed in early 2019, was built with React 16 and used Enzyme for unit testing. Over the past five years, the app grew, evolved, gained new features, and went though minor and major refactorings. Obviously, as responsible engineers we always maintained unit test coverage around 70-80%. However, our React version had remained unchanged.

By the end of 2024, it became clear that we couldn't delay the upgrade to React 18 any longer. But we faced a challenge: despite gradually adopting React Testing Library starting in 2021, we still had around 500 tests written with Enzyme. Unfortunately, enzyme-adapter-react-16 had been abandoned a while ago, and changes in React 18 engine made it impossible to use Enzyme at all.

We began creating tickets to refactor those Enzyme-based tests to RTL, but quickly realized that given our limited number of engineers, plus our ongoing business and maintenance obligations, rewriting all the tests in a reasonable time frame simply wasn't feasible.

We decided to explore a different solution: running two versions of React in our application. React 18 would be used for development and RTL unit tests, while React 16 would be retained exclusively for the Enzyme-based tests. This approach allowed us to upgrade without immediately refactoring all of our tests, buying us the time we needed.

Step #1: Two React versions

The first step was to configure our app to install both React versions. Fortunately, modern npm supports this kind of setup through aliasing.
We added the following aliases to our package.json:

"react-16": "npm:react@16.13.0",
"react-dom-16": "npm:react-dom@16.13.0"

Step #2: Identifying Enzyme Tests

Next, we needed to identify all the files using Enzyme. We did this by searching for files containing import { mount, shallow } from 'enzyme'; and then renaming those files to use the .enzyme.spec.js extension. This made it easier to differentiate them from the RTL-based tests.

Step #3: Configuring Jest to Run Two Projects

To handle both sets of tests, we configured Jest to run two separate projects—one for RTL and one for Enzyme. Below is our jest.config.js setup:

module.exports = {
  ...commonConfig,
  projects: [
    {
      displayName: 'R16 ENZYME - CONVERT ME ASAP!',
      testMatch: ['**/*.enzyme.spec.js'], // Only match enzyme-specific tests
      moduleNameMapper: {
        '^react(/.*)?$': 'react-16$1', // Map to old React 16 for Enzyme tests
        '^react-dom(/.*)?$': 'react-dom-16$1', // Map to old React-DOM 16 for Enzyme tests
      },
      setupFiles: ['<rootDir>/enzyme.config.js'],
      setupFilesAfterEnv: ['<rootDir>/jest-setup-enzyme.js'],
      snapshotSerializers: ['enzyme-to-json/serializer'],
      ...otherConfigs,
    },
    {
      displayName: 'R18 RTL',
      testMatch: ['**/*.spec.js', '**/*.spec.jsx'], // Match other test files
      testPathIgnorePatterns: [
        '\\.enzyme\\.spec\.js$', // Ignore Enzyme tests in this configuration
      ],
      setupFilesAfterEnv: ['<rootDir>/jest-setup.js'], // RTL-specific setup
      ...otherConfigs,
    },
  ],
};

In the React 16 project, we mapped react and react-dom to the aliased versions (react-16 and react-dom-16) in node_modules, ensuring that Jest would run with the Enzyme configuration for the .enzyme.spec.js files. Meanwhile, in the React 18 project, we used the jest-setup.js configuration and excluded the Enzyme test files.

Step #4: Enzyme Configuration

For Enzyme, we used the following enzyme.config.js file to configure the Enzyme adapter for React 16:

import 'regenerator-runtime/runtime';
import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

Conclusion

This isn't a perfect solution, but it allowed us to postpone the full refactor of 500 unit tests while enabling the upgrade to React 18. By maintaining dual React versions, we unblocked our path forward, striking a balance between immediate progress and technical debt management.
Our journey highlights that sometimes, pragmatic solutions serve as effective stepping stones. We plan to eventually migrate all tests to RTL, but in the meantime, this approach kept us moving without compromising our ability to deliver quality software.