Foundations: native versus custom components

Posted on Tuesday, 8 November 2022 by Ela Gorla

Deciding whether to use native or custom components for a website or web application can have implications in terms of development effort, user experience, and accessibility. This post considers the pros and cons of each approach with a focus on accessibility, and provides guidance on how to choose one.

HTML offers developers a wide range of native components that can be used "out-of-the-box". Buttons, links and form controls are all examples of such components. Web browsers also provide a number of standard features that developers can take advantage of, such as a default focus indicator (the border that appears when items receive the keyboard focus). Should developers rely on these native components and features, or should they build their own?

Both native and custom components and features come with benefits and drawbacks:

Native components require very little work, are familiar to users, and can be accessible by default (more on this later). On the other hand, they may not provide exactly the functionality or behaviour that developers are after
Custom components can be built to appear and behave exactly as developers wish, but they require a greater effort to build. Making them accessible can also be challenging

Deciding which ones to use is not always easy so here is a summary of things to consider around the accessibility of native and custom components and features. While not the only deciding factor, support for accessibility needs to be evaluated. Choosing components or features with a robust support for accessibility is likely to save you time and money in the long run.

When to use native components

Most of the native components in HTML provide accessibility benefits, including:

Support for screen readers and other assistive technology
Support for keyboard access
Consistent behaviour across browsers, operating systems and devices
Support for old versions of assistive technology that may not fully understand WAI-ARIA

As an example, the HTML native <button> element is:

Announced as "button" by screen readers
Identified as a button by voice recognition software
Focusable and actionable via the keyboard

Custom buttons have none of the above features by default and need to be made accessible. This means manually adding role information and implementing keyboard support, which require time and effort.

From an accessibility point of view, using the native version of simple components such as buttons, links and form controls greatly outweigh any possible drawbacks.

When to use custom components

There are cases, however, where using native components or standard features may not be the most accessible solution. Let me give you some examples.

Error messages

HTML5 input types allow developers to specify the type of data that people are expected to enter in input fields. By using HTML5 input types, developers can take advantage of browsers' built-in client-side error validation. This means they don't need to write long blocks of HTML and JavaScript to check that data is in the expected format and to display error messages otherwise.

A form containing several input fields. The error message "Please enter a URL" is displayed next to the "Website" field — A standard error message for a field of type `url` in Chrome.

This sounds like a great solution, which could also make error validation consistent across websites. Unfortunately, though, browser error messages present some accessibility and usability issues, described below.

They are not persistent

Browser error messages remain on screen for few seconds only. After that, there is no indication that the form contains errors, what the errors are, and how to resolve them. This is an issue for all users, and for people with disabilities in particular. For example, screen magnifier users may miss the error messages as they may be looking at a different area of the page, and people with some cognitive disabilities may not have time to read and process the error messages before they disappear.

A single error message is displayed at any one time

Upon submitting a form containing multiple errors, people are presented with one error message only. Only after re-submitting the form, do they find out that more errors are present. This can be frustrating and time-consuming, especially for keyboard and assistive technology's users who may take longer than mouse's users to reach the submit button at the end of forms.

No support for users' preferred font size.

Some people have their preferred font size set in the browser's settings and struggle to read text in a different size. While browsers' default error messages resize when the Zoom functionality is used, they do not honour users' font size choice.

Generic wording

In most cases, the error messages do not clearly explain what the problem with the entered data is and how to fix it. For example, "Please fill in this field" is displayed for every required field that is left empty. No indication of what data needs to be entered is provided. While some people can easily see the field's label together with the error message, it may take some effort for users of some assistive technology to do the same. Another example is the "Please enter an email address" error message displayed in Firefox any time an email address is entered in an incorrect format; some people may not know why the information they have entered is incorrect and what the expected format is.

Inconsistency between browsers

Each browser handles form validation and presents error messages quite differently. This creates inconsistency when accessing the same form in different browsers, which can be problematic for some people with cognitive disabilities.

Implementing custom error messages remains the most accessible solution until browsers address the above issues.

Focus indicator

Another standard feature of web browsers that can provide a poor user experience is the focus indicator. Again, each browser's implementation is different and while some provide a highly noticeable indicator, others do not. For example, here is Firefox's standard focus indicator, hardly visible around the "About us" link. It will be very difficult if not impossible for some keyboard users to notice it and know where they are on the page.

A navigation menu. A dotted border is hardly visible around one of the items, due to its low contrast with the background colour

We always recommend clients implement a custom focus indicator with a strong colour contrast against all background colours. For example, a dark purple border is displayed around links on our website. Not only does this make the focus indicator easy to perceive, it also makes it consistent across web browsers.

The navigation menu on the TetraLogical website. A dark purple border is visible around one of the links

Summary

In many cases, using native components and browser's standard features is the easiest and most accessible solution. This is particularly true for simple components that have been part of HTML for a long time, such as links, buttons and form fields.

While it is possible to implement support for accessibility using custom components, this requires more time and effort and is prone to errors. At the same time, you should not assume that all standard features are accessible by default. As the two examples above illustrate, some have accessibility and usability issues that are likely to impact the experience of people on your website and web applications.

Always research the accessibility support of native components and standard features before using them, or test them yourself with a range of assistive technology and accessibility settings. Conducting user research with people with disabilities is another effective way to find out what does and does not work for them.

Learn how our Assessments and Usability testing services can help you review the accessibility of your products and test them with people with disabilities. To learn more about the accessibility of HTML, read our HTML semantics post.