In creating a digital product, the product must be accessible to everyone, including people with disabilities. A product, website or mobile application, on the internet, should be created to be equally accessible to the disabled as the able-bodied. Accessibility in a digital product gives a product a larger audience than without it. According to the CDC, one in four adults in the US has some form of disability. As a product that caters for its users' needs unrestrictively, it reaches a wider audience than one with accessibility issues. Also, accessibility improves the user experience of a digital product. When users find it easy to click a button, navigate from one page to another, and perform an action on a product, they become happy, unlike the frustrations that come with squinting their eyes to see the texts on an app for the non-disabled, let alone people with eye disabilities. In summary, the more accessible a digital product is, the more satisfied users are with it, and the larger the product reach, all of which accumulate less stiff competition with companies of similar products.
Accessibility in a digital product aims to provide equal access to the resources the product offers regardless of the bodily conditions of the user. To enforce unrestricted access, the US Access Board developed the Section 508 standards to implement accessibility laws and requirements within ICT. Section 508 ensures that every ICT development is accessible to all and sundry, and people with disabilities can achieve the same feat on a product as an able-bodied person. The Section 508 standard is further supported by the Americans With Disabilities Act of 1990, which emphasises equal access to people with disabilities within public institutions (schools, hospitals, etc) and internet-based assets. To ensure the enforcement of these regulations within internet-based applications, the World Wide Web Consortium, W3C, developed the web standards for accessibility outlined in the Web Content Accessibility Guidelines, WCAG. Together, these standards and guidelines enforce equal access and interaction with the content of digital products.
The centrepiece of accessibility implementation on the internet is the client-side interface the user will interact with. Accessible frontend development ensures that individuals with varying abilities can access, interact, understand, and engage the web content, irrespective of their approach method. As a frontend developer, you’re tasked with enforcing accessibility standards in your applications, ensuring equal access and a profound user experience across the board. This article exposes common accessibility pitfalls in frontend development and how to avoid them, implementing ARIA attributes effectively in your application, and creating inclusive user interfaces for people with disabilities, among other accessibility issues and their solutions in frontend development.
Common Accessibility Pitfalls and How to Avoid Them
Let us explore some common accessibility pitfalls you might overlook as a frontend developer and their solutions.
Inadequate Keyboard Navigation
Recent web applications are designed and developed with a mouse navigation system as their default, neglecting users who depend partly or solely on keyboard navigation. People with motor and visual impairments heavily rely on their keyboard for website navigation. Without keyboard navigation, they face significant limitations. Besides disabled users, some prefer keyboard shortcuts to move a cursor about on the screen. These people are not left out of the limitations.
Solutions
- Make all interactive elements keyboard accessible.
- Implement a logical tab order.
- Provide visible focus indicators.
Poor Color Contrast
While aesthetics matters in the design of a website, the readability of the website content is also of paramount importance. Information is conveyed to the website users primarily through texts and illustrations. If the texts are then hidden in colours by a poor design choice, the website may end up resembling an art gallery of digital illustrations.
Solutions
- Design for colour blindness.
- Apply colour contrast in the appropriate ratios, 4.5:1 for normal texts and 3:1 for large texts.
- Use tools like WebAIM Contrast Checker to check and select accessible colour combinations.
Missing Alternative Text for Images
An image element alt text helps search engine crawlers index and rank an image properly by serving as the image description. Aside from its SEO usefulness, the alt attribute in images is essential for providing context to screen readers. Therefore, it's important to ensure that the text in the alt attribute is descriptive enough to paint a picture for visually impaired individuals accessing the website.
Solutions
- Always use descriptive alt text.
- For decorative images, use an empty alt attribute
alt="". - In case of an image that requires an extensive description, say an infographic, provide a detailed description in the texts after the image.
Inaccessible Forms
Forms are a way of communication between a user and a website, but a communication barrier can exist between both parties when the form is poorly integrated. Poor form integrations may include a lack of labels, descriptive placeholders, or clear CAPTCHA systems, as well as inadequate error handling.
Solutions
- Label form elements properly.
- In the absence of labels, use descriptive placeholders.
- Handle errors and form validation adequately.
- Provide clear instructions and feedback through toasts or modals.
- Use visual CAPTCHA alternatives, like audio. This will help the visually impaired.
- Use ARIA attributes to improve form accessibility for screen readers.
Non-Responsive Design
According to Research.com, 50.48% of web traffic came from mobile devices while the rest was distributed between desktop and tablet screens. Also, since 2020, mobile visits to a website have been 81% higher than desktop visits (Semrush, 2024). Over the years, various mobile phone companies have produced and sold different mobile screen designs. In summary, websites receive more visits from various mobile screen designs than desktops, necessitating responsive design and development of web applications by frontend developers. Developers who resist this change have forced users to zoom in and out of their devices to access website content, resulting in a frustrating experience.
Solutions
- Implement responsive designs across all screen sizes and orientations.
- It’s easier to implement responsive designs with recent CSS layouts such as Flexbox and Grid. Use them.
- Implement techniques for responsive typography such as CSS Clamp.
- Test your web application across several devices screens and screen readers.
Implementing ARIA Attributes Effectively
Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that define ways to make web content and web applications more accessible to people with disabilities (MDN). It helps to represent or replicate features of a semantic element widget in assistive technology devices.
As an accessibility-first developer, you can make the mistake of setting ARIA attributes to almost all HTML elements. This can be unnecessary as modern browsers now support HTML widget elements. These widget elements have built-in keyboard accessibility, roles, and states and should always be selected over using ARIA in all HTML elements.
For instance, take a look at this meter widget,
<meter value="2" min="0" max="10"></meter> <!-- Shows value on a scale -->
It is already meaningful in its present state, even to an assistive technology device. If unaware of its existence, you might be tempted to convert a regular div to a meter widget by setting roles and attributes with ARIA.
<div id="meter"
role="meterbar"
aria-valuenow="2"
aria-valuemin="0"
aria-valuemax="10">
</div>
Therefore, ARIA should only be used when a semantic HTML widget does not exist for the component you’re trying to build.
Common ARIA Attributes and Their Usage
ARIA attributes help modify the state and properties of an element as defined in the accessibility tree. It only modifies how assistive technologies render the element to your users but does not affect the function and behaviour.
ARIA states and roles fall into 4 categories: widget, live region, drag-and-drop, and relationship attributes. While these attributes are specific to their defined functions, ARIA has a list of general attributes applicable to all HTML elements.
Let’s take a look at some of the commonly used ARIA attributes.
-
aria-label: Thearia-labelattribute defines a string that adds more meaningful information to an interactive element. Some interactive elements can be poorly described because no attributes define their use. In this case,aria-labeladds context to the element’s purpose -
aria-hidden: Thearia-hiddenstate tells if an element is exposed to an accessibility API. Some elements can be purely for decorative purposes and have no specific semantic meaning. By settingaria-hiddento those elements, the accessibility API is freed from displaying them in assistive technology devices. However, it is important to note that this attribute should not be on a focusable element, its parents or ancestors. -
aria-expanded: Thearia-expandedproperty serves as an indicator of the control state of an element, if it is expanded or collapsed. It is usually used in button elements that control a widget, menu widget, combobox widget, and other collapsible elements. -
aria-controls: This property is used on an element to identify the element (or elements) it controls.
For a comprehensive list of common and less-popular ARIA attributes, visit MDN.
ARIA Roles and When to Use Them
ARIA roles describe elements that do not natively exist in HTML or exist without full browser support. ARIA roles provide semantic meaning to these HTML elements, allowing assistive technology devices to replicate the expected element interaction in a way that aligns with the user’s expectations of the object.
ARIA roles fall into 6 categories,
- Document structure roles: ARIA roles in this category provide structural descriptions for native HTML elements. Many semantic HTML elements have ARIA roles by default, but when using a generic element to create an object, you must pass a role to it. Document structure role provides assistive technologies more information about the document structure of the element. Some examples include toolbar, tooltip, feed, math, note, presentation, and more.
- Widget roles: Similar to document structure roles, it is used to provide descriptions, but in this case, for interactive patterns. Widget roles often require JavaScript for interaction. Combobox, menu, menubar, tab, switch, and scrollbar are a few examples of widget roles. > NB: There is a role named “widget” but it does not fall into the widget role category.
- Landmark roles: These roles help to identify the organization of a web page. Assistive technologies like screen readers use these landmark roles for keyboard navigation to sections of the app. Some of these roles are banner, contentinfo, form, main, etc.
- Live region roles: These roles define elements whose content changes dynamically. It is particularly useful for low-vision and blind users as it helps them know if an element's content has changed. Alert, log, marquee, status, and timer are the available live region roles.
- Window roles: Roles in this category define sub-windows within the main content window. For example, dialogs and modals create a sub-window, and these roles help to announce them in screen readers. Alertdialog and dialog are window roles.
- Abstract roles: Unlike other roles listed above, roles in this category are intended for use by the browser only and not for developers. The widget role falls in this category together with command, composite, input, landmark, range, etc.
See more ARIA roles and their uses here.
Best Practices for ARIA Implementation
Various ARIA roles can help to make your website more accessible, but not all of them are essential. This is because many of these ARIA roles are already covered by semantic HTML elements. For example, some roles in the document structure category and all in the landmark category have corresponding semantic HTML elements supported by browsers. Therefore, instead of adding ARIA roles to every element, it's important to check if a semantic HTML equivalent exists.
Also, it's crucial to test ARIA implementations with screen readers to ensure they convey the intended information without confusing users. And finally, refrain from using abstract roles in your app. They are, as stated, for browsers only.
Conclusion
Accessibility is an essential factor to consider when building software applications. It ensures that your app does not restrict users, regardless of disability. As a frontend developer, it is important to enforce accessibility in all your applications, whether small, medium, or large. In this way, your app will serve its purpose without issues, and your users will be satisfied.
Follow me on X @theDocWhoCodes to learn more about what I do and write about.
Cover Photo by fauxels
Top comments (4)
This is an excellent primer. Thank you.
Creating an inclusive web is of utmost importance. Accessible frontend development ensures that everyone, irrespective of their abilities, can easily navigate and interact with the website.
Great guide. Thanks, Mike. Additionally, here's a great place to find the most helpful accessibility tools in one place.
very nice