Many software engineers have great app ideas they’re eager to build outside of work — but with so many different specializations in tech, accessibility and UX best practices are areas many engineers haven’t had much exposure to. If that’s you, making sure your app is accessible might feel like an overwhelming extra challenge. In this post, I’ll share practical, high-impact strategies to help you cover a lot of basic accessibility ground with minimal effort. These tips won’t get you all the way to perfect WCAG compliance, but they will make a big impact in making your app more accessible. Leverage UI component Libraries with Built-In Accessibility If front-end development isn’t your specialty, using a component library is a smart move. It can save you significant development time by providing pre-built, well-designed components that ensure your app looks consistent, cohesive, and follows front-end best practices — all without requiring you to master them yourself. By choosing a component library that prioritizes accessibility, you also get WCAG-compliant components right out of the box, without the extra effort of building them from scratch. Just keep in mind that some accessibility features may require specific setup or configurations, so it's a good idea to review the documentation for each component you use. Recommended libraries: Mantine (React)  - Mantine is a customizable component library that prioritizes accessibility and has over 100 components and 50 hooks. Their components all follow WAI-ARIA guidelines, and are screen reader compatible. For more details on how they ensure accessibility, check out their accessibility docs. Mantine check out their accessibility docs Radix UI (React, Vue) - Radix UI is another option that provides excellent accessibility support. However, they are unstyled - which is great if you want more control over the appearance of your app, but if you are looking to have as much out of the box FE work taken care of, a library with more styling may be a better way to go. For more info on Radix UI’s accessibility, check out their docs here. React Vue check out their docs here PrimeVue (Vue) - PrimeVue is a comprehensive suite of UI components, icons, and application templates that can be used either styled or unstyled. They prioritize accessibility and are WCAG 2.1 AA compliant. Their docs on accessibility can be found here. PrimeVue Their docs on accessibility can be found here Understand Basic Accessible Design Fully mastering WCAG-compliant design likely requires more time than a software engineer exploring a side project is willing to dedicate. The following guidelines, however, are a great starting point - they are straightforward to implement and cover some of the most common barriers faced by disabled users. Make sure color contrast is high enough - so that everything can be read clearly, even if the user has visual impairments. WebAIM has an easy contrast checker where you can quickly check your font and background colors have high enough contrast.
Color should never be the sole signifier of anything - colorblind users will not be able to distinguish the difference. For instance, if a user types an invalid response in an input, just changing the input to having a red border is not enough - there should be an error message and maybe an icon.
Errors should be specific - ie, “Date of birth must be in format MM/DD/YYYY” rather than “Fix form errors” or “invalid input”
Use labels, not placeholders - placeholders are written in low contrast colors, they disappear when the user starts typing, and they can’t be discerned by screen readers. Using labels will support users with visual impairments and memory issues. Make sure color contrast is high enough - so that everything can be read clearly, even if the user has visual impairments. WebAIM has an easy contrast checker where you can quickly check your font and background colors have high enough contrast. Make sure color contrast is high enough contrast checker Color should never be the sole signifier of anything - colorblind users will not be able to distinguish the difference. For instance, if a user types an invalid response in an input, just changing the input to having a red border is not enough - there should be an error message and maybe an icon. Color should never be the sole signifier of anything Errors should be specific - ie, “Date of birth must be in format MM/DD/YYYY” rather than “Fix form errors” or “invalid input” Errors should be specific Use labels, not placeholders - placeholders are written in low contrast colors, they disappear when the user starts typing, and they can’t be discerned by screen readers. Using labels will support users with visual impairments and memory issues. Use labels, not placeholders Add Description Anywhere You Can Add in more description than you think is needed. This not only supports users with cognitive impairments, users who use screen readers, and users with memory issues; it makes your app more intuitive and user friendly to everyone. Make sure all form inputs have labels (not just placeholders)
Make sure buttons and links are descriptive - be clear about what the link or button does.  For instance, “Click here to read more about Alaskan Malamutes” rather than just “Click here”; or “Confirm your order” instead of just “Confirm”
Make sure buttons without text have aria-labels - An aria-label will be read by a screen reader. So if you have a button that has a magnifying glass icon to indicate this is the search button, you would add an aria-label like “Search”
Add descriptive and helpful alt tags to images - Avoid using SEO keywords, file names, or generic words like "image" in your alt text. Screen readers read the alt text aloud when users reach an image, so write a description that would make sense if someone were verbally describing the image to you. For purely decorative images, set the alt attribute to an empty string (''), and screen readers will automatically skip over them. Make sure all form inputs have labels (not just placeholders) Make sure all form inputs have labels Make sure buttons and links are descriptive - be clear about what the link or button does.  For instance, “Click here to read more about Alaskan Malamutes” rather than just “Click here”; or “Confirm your order” instead of just “Confirm” Make sure buttons and links are descriptive Make sure buttons without text have aria-labels - An aria-label will be read by a screen reader. So if you have a button that has a magnifying glass icon to indicate this is the search button, you would add an aria-label like “Search” Make sure buttons without text have aria-labels Add descriptive and helpful alt tags to images - Avoid using SEO keywords, file names, or generic words like "image" in your alt text. Screen readers read the alt text aloud when users reach an image, so write a description that would make sense if someone were verbally describing the image to you. For purely decorative images, set the alt attribute to an empty string (''), and screen readers will automatically skip over them. Add descriptive and helpful alt tags to images Use Semantic HTML Semantic HTML is much more screen reader friendly than using divs for everything. If you are writing any HTML yourself, use semantic HTML elements like nav, footer, header, main. Additionally, use button and anchor tags for their intended purpose - don’t use anchor tags for buttons or vice versa. Leverage Existing Accessibility Testing Frameworks Luckily, there are quite a few accessibility testing libraries that work pretty well out of the box, which means you can test your app’s accessibility without devoting a great deal of time writing accessibility-related unit tests. Lighthouse - Lighthouse offers both a browser tool and a tool that can run accessibility audits as part of a CI/CD pipeline. Lighthouse Axe-core testing library - The company Deque created libraries that work with multiple front end testing libraries (including Jest, React Testing Library, Enzyme, Jasmine, Mocha, etc). Once you install the library and call it, it runs all the tests for you. Axe-core testing library Building an app solo is a huge undertaking - and it’s no surprise developers focus on what can make the most impact. However, accessibility doesn't have to be something that is left out. By using the strategies and tools outlined here, you can significantly improve the accessibility of your app with minimal effort. Whether it’s leveraging UI component libraries, ensuring semantic HTML, or adding descriptive labels and alt text, these small adjustments can make a big difference in creating an app that’s more inclusive for all users. Accessibility isn’t just about compliance — it’s about providing a better, more intuitive experience for everyone, and these foundational steps are a great place to start.

Accessibility Quick Start: High Impact Practices for Non-Frontend Devs

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

7 Ways to Up Your TypeScript Game

0–100 in Django: Starting an app the right way

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: OpenAI is Sam Altman; Sam Altman is OpenAI (11/30/2023)

The Noonification: Panda Power (11/28/2023)

The Noonification: Feature Optimization for Price Prediction (11/26/2023)

7 Ways to Up Your TypeScript Game

0–100 in Django: Starting an app the right way

The Noonification: How to Deal With Flapping or Broken Tests (11/29/2023)

The Noonification: OpenAI is Sam Altman; Sam Altman is OpenAI (11/30/2023)

The Noonification: Panda Power (11/28/2023)

The Noonification: Feature Optimization for Price Prediction (11/26/2023)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps