How I became a conference speaker (and how you can too!)
This is how I got into conference speaking as a software engineer, and how you can too.
Do you consider web accessibility when building your web and mobile applications? Most developers don't! In this post, we'll dive deeper into web accessibility, why it’s important, and who’s responsible for defining accessibility standards.
By the end of this article, you’ll know the key principles of accessibility and how to apply them to every project.
Why Care About Accessibility?
Web accessibility isn't just a tick on a compliance checklist—it's a core pillar of responsible, user-centered design. Here's why it should matter to you:
-
Global Requirement: Digital accessibility is now required for many websites and apps worldwide. In the Netherlands, this applies to all government bodies, including national, regional, and local authorities, as well as public institutions and certain partnerships—known collectively as "overheidsorganisaties" (government organizations).
-
Legal Risks: Ignoring accessibility can cost a business a ton of money! For example, Target faced a $6 million lawsuit for not complying with accessibility guidelines. In Europe, fines under the European Accessibility Act (EAA) can reach €20,000–€50,000 per infringement, depending on the country and severity.
-
A Large, Overlooked Audience: Over 1 billion people worldwide live with a disability, many of them with invisible conditions. If your site isn’t accessible, you’re making it harder for a huge group of people to use the web.
-
Inclusive Design Benefits Everyone: Accessibility isn’t just about how things look—it’s about making sure everyone can use your site, no matter their abilities. Inclusive design helps people with things like dyslexia, epilepsy, color blindness, hearing loss, and more.
-
SEO Boost: Accessibility practices—like alt text, semantic HTML, clear headings, audio/video transcripts, and keyboard-friendly design—not only support all users but also improve SEO, boosting search visibility and rankings.
What Defines Accessibility? WCAG and Its Importance
The Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C), are the global standard for web accessibility. They outline the rules to make websites easier to use for people with disabilities, including sensory, cognitive, and physical challenges.
WCAG is organized into three levels:
- A (Minimum): Basic rules that all websites should follow.
- AA (Mid-range): More common and balanced rules, often required by law.
- AAA (Highest): The best level of accessibility, but hard to do for every site.
Versioning of WCAG: The guidelines have evolved over time, with the following major versions:
- WCAG 1.0 (1999): The original version, mostly focused on HTML websites.
- WCAG 2.0 (2008): A major update that applies to all kinds of web content and technologies.
- WCAG 2.1 (2018): Expanded to better address mobile devices and the needs of people with cognitive or low vision impairments.
- WCAG 2.2 (2023): The most recent version, which includes improvements for cognitive disabilities and navigation.
For example, in the Netherlands, the websites and apps mentioned above currently need to meet the WCAG 2.1 AA standard.
--
Since the guidelines are always evolving, it’s a good idea to check out the WCAG guidelines yourself.
The good thing is, they’re all built around four core principles, and once you get those down, you’ll be ahead of the game compared to most people!
The 4 Core Accessibility Principles (POUR)
WCAG organizes requirements into four principles: Perceivable, Operable, Understandable, and Robust (POUR).
Below is a breakdown of these principles with code examples to illustrate best practices.
1. Perceivable: Ensure All Content is Usable by Everyone’s Senses
Provide Alt-Text
Use descriptive alt text for all images, especially those conveying important information. Avoid generic labels like “image” or “photo”—alt text should describe the content or function, e.g., “Person in wheelchair using a computer.”
<!-- BAD EXAMPLE: Generic or missing alt text --> <img src="chart.png" alt="image"> <!-- GOOD EXAMPLE: Descriptive alt text --> <img src="chart.png" alt="Line chart showing quarterly sales growth from 2019 to 2020">
Responsive Design
Don’t just design for one screen. Use responsive design techniques to ensure all visual elements adapt to various screen sizes, including zoom and screen readers.
Color Contrast
Use high-contrast color schemes, especially for text. Aim for a contrast ratio of at least 4.5:1 for body text to ensure readability, and avoid color-dependent instructions (e.g., “click the green button”).
Transcripts and Captions
Provide text alternatives for audio and video content. This benefits not only users with hearing impairments but also those in quiet (or loud) environments who may not be able to use audio.
Developer Tip: Use tools like the Color Contrast Analyzer to test your design’s readability, especially for color-blind users.
2. Operable: All Features Must be Functional Across Devices and Methods
Keyboard Navigation
Make sure your site works well with just the keyboard. Users should be able to navigate with Tab (forward) and Shift + Tab (backward), and activate elements with Enter or Space.
Use tabindex to set a logical focus order, and always show visible focus indicators so users know what they’re on. All essential actions, like submitting forms and navigating, should be easy without a mouse.
<!-- Use tabindex to ensure focus is in the correct order --> <a href="#content" tabindex="1">Skip to Content</a> <button tabindex="2">Submit</button>
Avoid Flashing Content
Any flashing or blinking content should not flash more than three times per second to avoid triggering seizures in users with epilepsy.
Time-Sensitive Controls
If your website includes timed actions (like a countdown), provide users with options to extend or disable the timer.
Clear Focus Indicators
Ensure focus states are visible and distinguishable. This is crucial for users who navigate via keyboard.
/* Visible focus indicator */ button:focus { outline: 2px solid #0055cc; outline-offset: 2px; }
Developer Tip: Test your app’s keyboard operability by tabbing through each interactive element. Look for skipped or inaccessible sections.
3. Understandable: Make Content Clear and Predictable
Set Language Attributes
Properly set the language attribute (lang) on your HTML elements. This helps screen readers determine pronunciation and interpretation.
<html lang="en"> <!-- Content here --> </html>
Simplify Text
Avoid jargon and complex sentences. Aim for an 8th-grade reading level to ensure clarity for a broad audience. If you must use specialized terms, define them in a tooltip or glossary.
<!-- Provide explanations for jargon --> <p>The <abbr title="Application Programming Interface">API</abbr> is essential for connecting services.</p>
Consistent Navigation
Keep navigation consistent across all pages. Erratic changes can confuse users who rely on screen readers or keyboard navigation.
Error Handling
When form validation errors occur, ensure they are clearly described and labeled. Use ARIA attributes (e.g., aria-describedby) to announce errors to screen readers.
<label for="email">Email:</label> <input type="email" id="email" aria-describedby="error-email"> <span id="error-email" aria-live="assertive" style="color: red;">Please enter a valid email address.</span>
aria-live tells assistive technologies that content in a specific area may change dynamically. The values of aria-live determine how and when these changes are read aloud to users by screen readers:
polite: Changes are read aloud after the user finishes their current task, so it doesn’t interrupt their experience.assertive: Changes are read aloud immediately, interrupting the user’s current activity. This is useful for important updates like error messages.
4. Robust: Ensure Compatibility with Various Devices and Assistive Technologies
Semantic HTML
Use HTML5 semantic elements (header, <nav>, <article>, <footer>) instead of relying solely on <div> and <span> elements. This ensures screen readers can interpret the content correctly.
<!-- Use semantic elements instead of divs for structure --> <nav>Navigation here</nav> <main>Main content here</main> <footer>Footer content here</footer>
Use ARIA Where Necessary
While ARIA attributes are powerful, they should be used sparingly and only when native HTML cannot achieve the same functionality. Overuse can actually confuse assistive technologies.
<!-- Use ARIA only when necessary --> <button aria-label="Close modal">X</button>
Developer Tip: Use the W3C’s Markup Validation Service to ensure your HTML is valid.
Testing Your Website for Accessibility Compliance
Automated testing tools are a great starting point, but manual checks are key to catching things automation might miss. Here's a combo approach:
- Automated Tools: Use tools like Axe, Lighthouse, and WAVE to quickly identify accessibility issues.
- Manual Testing: Test with screen readers and try navigating just with your keyboard. Put yourself in the users' shoes and experience your app like they would. Here are some examples of screen readers that you could use for testing:
Our Approach to Accessibility
At FrontValue, we know how important accessibility is for our clients. With many of them needing to meet WCAG standards set by the Dutch government, we’ve built processes to keep projects compliant and inclusive from the start.
{ "files": [ "*.html" ], "rules": { "@angular-eslint/template/prefer-control-flow": "error", "@angular-eslint/template/alt-text": "error", "@angular-eslint/template/elements-content": "error", "@angular-eslint/template/no-positive-tabindex": "error", "@angular-eslint/template/table-scope": "error", "@angular-eslint/template/valid-aria": "error", "@angular-eslint/template/click-events-have-key-events": "off", "@nx/workspace-gm-click-events-have-key-events": "error", "@angular-eslint/template/mouse-events-have-key-events": "error", "@angular-eslint/template/no-autofocus": "error", "@angular-eslint/template/no-distracting-elements": "error" } } // Credit to Nicky Haze for sharing his project configuration
A big part of that is setting up ESLint rules that help us catch accessibility issues early, so things like alt text, ARIA labels, and table scopes are all in place right in the code.
We’ve even written some custom ESLint rules ourselves to keep our apps extra accessible!
Final Call to Action
Don't treat accessibility like it's something you can squeeze in at the last minute. Make it a priority, and you'll widen your audience, improve usability, and build a web that works for everyone. So, jump in and start testing accessibility in your next project—no room for excuses!
