When I started my journey into web design by making websites, I only cared to make it look beautiful. I didn't know what UX was or was the website usable. Making things look good is all fine but when you step out to put your content online, do you not want it to be accessible to all? So this blog is my foray into web accessibility and I will layout some of the ways we could make our apps more accessible with minimum efforts.

If you don't want to read the preface, jump right to the meat ⬇️

What is Web Accessibility ?

So, accessibility often abbreviated as a11y (a followed by 11 characters in accessibility before y) is basically about being empathetic and allowing more people to access your apps.

But WHY?

The web is diverse place, meant for everyone irrespective of their hardware, language or ability. We tend to ignore the people with motor disabilities and sight related issues, considering them as minority users.

Also, accessibility is something that concerns all of us not just the disabled. As we age our senses tend to get weak. Funny that the so-called "boomers", who are at their 50's now having seen the web boom and tech evolve over the years, find it hard to use our apps. Or forget them, think of YOU as you get old struggling at reading this blog and navigate a fancy app made by you yourself ? Would you create something that turns useless to a 60 yr old YOU ?

Now accessibility is making sense, isn't it ?

Small steps to bring a change

So what can we do to our code to ensure the applications we make are more accessible? Or how do I become an a11y?

Here are some small steps you can take to gain accessibility with minimal development. These are not all, but decisions I have started making consciously when designing my web applications. We'll look at other relevant and useful guides on a11y by the end of this blog.

Semantics.

Yes. Use of proper HTML semantics play a big role in making your app accessible.

Haven't heard about semantic HTML ? Have a quick read here

Semantic tags make it clear to the browser what the meaning of a page and its content is. When a screen reader, or any sort of assistive device scans the web page, it understands the structure of the page. Screen reader software like JAWS or NVDA doesn’t just turn text into speech - it can use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, or announce how many items are in a list, among other things.

• <div> and <span> are semantically meaningless. There are more meaningful tags, so stop using divs recklessly. Use these containers only for layouts.

• Use <nav>, <main>, <section>, <footer> elements to structure your page. Note that screen readers use them as guideposts.

• Headings.

  • Have only one <h1> per page, for the page title.
  • Don't skip heading level tags, skipping for e.g using <h3> before <h2>, breaks page structure and can confuse screen readers.

Bad Markup

     <font size="8">Page Title</font>
     <br><br>
     <div>This is my first para with some text</div>
     <br><br>
     <font size="5">Subheading 1</font>
     <br><br>
     <div>This is my first subsection for my content</div>
     <br><br>
     <font size="5">Subheading 2</font>
     <br><br>
     <div>This is my second subsection for my content</div>

Good Markup

     <main>
       <h1>Page Title</h1>
       <p>This is my first para with some text</p>
       <section>
         <h2>Subheading 1</h2>
         <p>This is my first subsection for my content</p>   
       </section>
       <section>
         <h2>Subheading 2</h2>
         <p>This is my second subsection for my content</p>   
       </section>
     </main>

See the difference ? That's the beauty of semantic tags.

Use the right elements

• Some elements have native accessibility. Elements like <input> and <button> have the default behavior of being able to be selected via keyboard, support the ENTER or SPACE keys to perform actions, announced properly by the screen reader. So next time avoid using <div> with a click handler.

• Links are meant for navigation while buttons are meant for actions. Adding an onClick on <a> is considered an accessibility pitfall.

Learn to label

Adding relevant labels to your elements adds greatly to the experience of your users who are visually impaired as screen readers pick out the associated labels and read them out.

• While browsers might use the textual content of certain elements like buttons as its label other input elements may not have an associated text with them. So, wrap your text and checkboxes with a <label>. Make sure the for attribute matches the id of the input field you are labeling.

• Provide text alternatives for all non-text content like images, icons etc so that it is accessible to people with disabilities. Make sure alt attribute is as descriptive as possible, so it tells the screen reader how the image looks.

Visual Indicators👀

Hovers. We all would have used this while styling our navigators. Hover states give a visual indication and differentiate interactive elements from the non-interactive elements on the page. While these might not help a lot, but these are nuances that really contribute to the user experience.

Input elements by default have a visual indicator. The blue outline you see on your HTML input fields or buttons when clicked ? yes, the focus ring. Focus indicates which element on the page is ready to accept a keyboard event. You could look at them as the mouse pointers for folks using keyboard for navigation.

Final words...

I must confess, I am not an 'a11y' yet. These were some of my learning so far, that I wanted to share with you. There are dedicated projects working on the mission of making web accessible. You should check them out and learn more about accessibility.

Did you know there are attributes that specifically aim at making web content and web applications more accessible ? ARIA. Please do read about it.

So what should be your take away from this blog? I think to be empathetic, putting the user first and thinking of their experience while designing your interfaces.

Additional resources

• The A11Y Project
• Web Accessibility Testing