Prologue
A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component.
In my last article, I covered creating the underlying data structures for supporting keyboard handling between components.
This article, along with its accompanying release, focuses on the design and styling of a navigation component whose first row is laid out vertically, consistent with mobile navigation.
Note: This article is one of a series demonstrating how to build a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each building on the previous, until a fully implemented navigation component is complete.
Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 0.5.1.
While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x. Examples use Next.js 16.x, which is not required to run the navigation component.
Follow along either by downloading the release and running the examples while examining the codebase, or by activating the link accompanying each code snippet to view the full file on GitHub.
This article is fairly long. It contains code and explanations. The code for this release is displayed, and the corresponding GitHub source is linked. Use these anchor links to move to the items of interest.
Content Links
Introduction
Earlier, I went through creating layouts for a navigation component suitable for desktop or laptop widths. This time, I want to focus on a layout for the same component that is suitable for mobile devices.
Between my insistence that all my flow-control elements (those that always begin on a new line when the default positioning of static is applied) default to no specific width of their own and my use of nested CSS to style, I'm finding it much easier to achieve layouts.
In my experience, the longer a website has existed, the more fragile its CSS becomes. Whether the CSS is styled in separate sheets or inside the components, it becomes a struggle to keep everything consistent. Multiple classes are chained together, and name-spaces are prepended onto them in an attempt to stop one style from stepping onto another. Styling within a component seems simpler, but is it really?
Structural HTML doesn't just help screen readers; it's also useful when styling the screen. There's something freeing about styling an entire component with a single class and using descendant and sibling selectors. Styles become easier to trace, and I'm no longer puzzling over which styles are targeted, a situation that tends to hinder debugging style issues, especially if a styling library is misconfigured and production-level obfuscation is applied in development. Add layer rules, ensure browser styling is consistent, and working with CSS becomes a smooth flow rather than a fight.
The selectors I used in the horizontal layout are still applicable to this vertical layout; the only differences are the initial class and the rules within the selectors. In this case, the top row will be vertically aligned rather than horizontally. The pattern is still one of disclosure, but it should follow the keyboard rules for an accordion rather than a menu.
Initially unstyled, the navigation component, while not yet polished, still reflects the basic shape I'm looking for. Thanks to the [data-orientation="vertical"] passed to the vertically aligned menu, the List component sets up the initial layout right away.
Spacing is a mess, buttons are ugly, and nothing really lines up. However, even with these issues, it's still operable and understandable.
Layout
Top Row Layout
Recall that everything in React eventually becomes plain old HTML, and the structure defined for the navigation output details the styling order in Nested CSS.
<nav>
<ul>
<li><a href="#" id="item-one">Item One</a></li>
<li><a href="#" id="item-two">Item Two</a></li>
<li>
<button id="item-three">Item Three</button>
<ul id="subnav-1">
<li><a href="#" id="item-four">Item Four</a></li>
<li><a href="#" id="item-five">Item Five</a></li>
<li>
<button id="item-six">Item Six</button>
<ul>
<li><a href="#" id="item-seven">Item Seven</a></li>
<li><a href="#" id="item-eight">Item Eight</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</nav>
HTML Structure, Top row targeted in the CSS.
@layer system-component {
nav.vertical-navigation {
/* Layout */
padding: calc(var(--sp-px) * 16);
/* Top Row nav > ul > li */
& > ul {
& > li {
& > button,
& > a[href] {
padding-left: 0;
justify-content: flex-start;
}
}
}
}
}
GitHub (release 0.5.1) - styledVertical.css
Since the nav element has only one direct descendant, almost everything except padding is targeted by the unordered list's enclosing styles, which are directly contained within the nav element. Direct descendants always use a > and so anything contained within the direct unordered list will be styled accordingly, while nothing outside will be affected.
The styling in this bit only targets the top row through another direct descendant, & > li {} is set and then buttons and links that are direct descendants of the top row list items are set to justify the content within to a left alignment (flex-start), which overcomes the button's default alignment of center.
SubList Layout
The subnavigation lists and focusable elements are next.
& > ul {
… /* Top Row */
& > ul {
& li {
width: 100%;
}
& > li {
& button,
& a[href] {
flex-wrap: nowrap;
justify-content: flex-start;
padding: calc(var(--sp-px) * 16);
}
}
& ul {
& > li {
padding-left: calc(var(--sp-px) * 16);
}
}
}
Any unordered lists that are the direct descendants of the top row list items are then targeted. List items are given a width of 100% to help with the target size, and buttons and links that are direct descendants of the sub-lists are given some padding to visually distinguish them from the primary list, with the content left-aligned.
Styling based on elements, descendants and siblings maps CSS onto the structure, increasing readability and maintainability. It's easier to figure out where something is being applied, which makes fixes much easier.
Focusable Element Standardization
& li {
& a[href]{
display: inline-block;
}
& button,
& a[href] {
background-color: transparent;
border-color: transparent;
border-radius: 0;
border-width: calc(var(--sp-px) * 2);
color: var(--component-text-color);
min-height: calc(var(--sp-px) * 16);
padding-top: calc(var(--sp-px) * 4);
padding-bottom: calc(var(--sp-px) * 4);
width: 100%;
text-align: left;
}
}
Styling outside of components makes it easier to apply CSS consistently. Consider that buttons and links live in their own navigation components. Buttons are contained in the SubNavigation component while links live in the NavigationItem. When CSS is applied either via Tailwind classes or within the component itself, the styles need to be applied separately and maintained consistently. It's frustrating, and at some point, a developer may overlook that changes in one file require changes in another.
In this case, I can target buttons and links together to maintain consistency. Spacing is made consistent by setting the link element to display: inline-block, which allows width and a minimum height to be applied, along with some top and bottom padding.
Buttons and links are given a 100% width. By expanding the button's width to fill the entire list item, the target size increases, making it easier for someone using a pointer of any sort, mouse, finger or tracking device to actually interact with a particular button.
Removing the default background and border colors and standardizing the padding work wonders, moving the layout from ugly to more professional.
Separators and Weights
The font weights are inconsistent between the buttons and links, and some separation is needed to clarify the difference between the primary and subsequent lists.
& > ul {
& li:has(button) {
border-bottom-width: calc(var(--sp-px) * 2);
border-bottom-color: var(--component-border-color);
border-bottom-style: solid;
padding: calc(var(--sp-px) * 4) inherit;
&:has(button[aria-expanded="true"]) {
border-bottom-color: transparent;
& > button {
border-bottom-color: var(--component-border-color);
}
}
}
& button,
& a[href] {
font-weight: 400;
}
& > ul {
padding-top: calc(var(--sp-px) * 8);
}
}
Have you ever wanted to style an element base on something it contains or an attribute a child element exposes? Modern CSS supports it through the :has pseudo-selector.
If the list item contains a button, it is given a bottom border that disappears when the button within it is expanded. When the button is expanded, the list border is set back to transparent and the bottom border moves to the button.
The :has () pseudo-selector allows for the application of a style to a parent element based on specific attributes of a child element. In this case, whether the button has exposed the attribute, aria-expanded="true". When it does, both the parent and the child can be styled together by moving the colored border from the bottom of the list to the bottom of the button.
&:has(button[aria-expanded="true"]) styles the list item when it has a button with the attribute aria-expanded="true". I prefer using existing attributes rather than creating new classes. It creates a more readable, understandable stylesheet and better details the required state than something applied as a class.
Summary
Testing with larger browser font sizes confirms proportions and ratios are consistent.
Structural HTML, Layers and Nested CSS are natural allies, creating an understandable, traceable and maintainable set of styles. The stylesheet can be stored alongside the component and configured to affect only the component itself.
In my next article in this series, I'll be implementing keyboard navigation using the up and down arrow keys to shift focus between components.
Top comments (0)