Accessibility as a core principle
Accessibility is one of those things that often gets pushed to "later" (which usually means never). When you're working on a side project or racing to meet a deadline, it’s easy to skip it. But here’s the problem: ignoring accessibility now is like planting landmines in your own codebase. As your project grows, those “quick hacks” turn into a nightmare. Users start running into issues, fixing them becomes way harder than it should be. And look, accessibility isn’t just about compliance. It’s about building stuff that actually works for real people—including those with disabilities. There are small, practical things you can remember that’ll have a huge impact. Let’s dig into them. Do not use href="#" in . Users who rely on screen readers or keyboard navigation expect links to go somewhere. If href="#" is used without proper handling, the screen reader might announce it as a link, but it doesn’t actually navigate anywhere, which can be confusing. Use instead of for interactive elements. Buttons are focusable, keyboard-accessible, and provide built-in semantics for assistive technologies. Use proper heading structures ( to ) in the correct order. Headings help screen readers and users quickly understand page structure and navigate efficiently. Use for form inputs to provide clear context. Username: Color contrast. Low contrast text is difficult to read for users with visual impairments. (Checking contrast is easy in DevTools) Keyboard navigation matters. Not all users rely on a mouse—some navigate solely using the keyboard. Your site should be fully accessible via the Tab key. Ensure all interactive elements can be focused with Tab. Use :focus styles to highlight active elements. Avoid tabindex="-1" unless necessary. Provide alternative text for images Use ARIA wisely ARIA (Accessible Rich Internet Applications) helps with accessibility but can be tricky to use correctly. Use native HTML whenever possible and keep ARIA simple. Accessibility isn’t an all-or-nothing deal. Even small improvements can make a big difference. The earlier you integrate accessibility into your workflow, the better experience you’ll create for everyone. Let’s not wait until it’s a problem. Let’s build accessible web experiences from day one.

Accessibility is one of those things that often gets pushed to "later" (which usually means never). When you're working on a side project or racing to meet a deadline, it’s easy to skip it.
But here’s the problem: ignoring accessibility now is like planting landmines in your own codebase. As your project grows, those “quick hacks” turn into a nightmare. Users start running into issues, fixing them becomes way harder than it should be.
And look, accessibility isn’t just about compliance. It’s about building stuff that actually works for real people—including those with disabilities.
There are small, practical things you can remember that’ll have a huge impact. Let’s dig into them.
Do not use href="#"
in
.
Users who rely on screen readers or keyboard navigation expect links to go somewhere. If href="#" is used without proper handling, the screen reader might announce it as a link, but it doesn’t actually navigate anywhere, which can be confusing.
Use
instead of for interactive elements.
Buttons are focusable, keyboard-accessible, and provide built-in semantics for assistive technologies.
Use proper heading structures (
to
) in the correct order.
Headings help screen readers and users quickly understand page structure and navigate efficiently.
Use for form inputs to provide clear context.
Color contrast.
Low contrast text is difficult to read for users with visual impairments. (Checking contrast is easy in DevTools)
Keyboard navigation matters.
Not all users rely on a mouse—some navigate solely using the keyboard. Your site should be fully accessible via the Tab
key.
- Ensure all interactive elements can be focused with Tab.
- Use
:focus
styles to highlight active elements.
- Avoid
tabindex="-1"
unless necessary.
Provide alternative text for images
Use ARIA wisely
ARIA (Accessible Rich Internet Applications) helps with accessibility but can be tricky to use correctly. Use native HTML whenever possible and keep ARIA simple.
Accessibility isn’t an all-or-nothing deal. Even small improvements can make a big difference. The earlier you integrate accessibility into your workflow, the better experience you’ll create for everyone.
Let’s not wait until it’s a problem. Let’s build accessible web experiences from day one.
Buttons are focusable, keyboard-accessible, and provide built-in semantics for assistive technologies.
Use proper heading structures (
to
) in the correct order.
Headings help screen readers and users quickly understand page structure and navigate efficiently.
Use for form inputs to provide clear context.
Color contrast.
Low contrast text is difficult to read for users with visual impairments. (Checking contrast is easy in DevTools)
Keyboard navigation matters.
Not all users rely on a mouse—some navigate solely using the keyboard. Your site should be fully accessible via the Tab
key.
- Ensure all interactive elements can be focused with Tab.
- Use
:focus
styles to highlight active elements. - Avoid
tabindex="-1"
unless necessary.
Provide alternative text for images
Use ARIA wisely
ARIA (Accessible Rich Internet Applications) helps with accessibility but can be tricky to use correctly. Use native HTML whenever possible and keep ARIA simple.
Accessibility isn’t an all-or-nothing deal. Even small improvements can make a big difference. The earlier you integrate accessibility into your workflow, the better experience you’ll create for everyone.
Let’s not wait until it’s a problem. Let’s build accessible web experiences from day one.