Are you sure that your website is accessible?

menuThere are plenty things we keep in mind while designing a website. Responsiveness, time of loading, eye pleasing intuitive interface are just some of them, but are we ready to ask ourselves “is my website accessible? What does it even mean?” So what about accessibility?

Let people use what they already use.

The worst we can do is to enforce users to abandon their habits of using websites. Extreme example is highjacking browser url when doing browser-side routing and not handling default “before/forward” navigation buttons in browser. This can cause a lot of confusion and frustration to our site’s visitors. Some people want to enlarge a website by pressing `Ctrl/Cmd +` or changing default browser font size. There is a number of convincing reasons why it’s helpful, eg. some details of a photo might be too tiny on a mobile or they have difficulty to read the content, because of the small font. Therefore it’s generally a bad idea to prevent users from zooming by using:

<meta name="viewport" content="initial-scale=1, maximum-scale=1">

instead of that, what we, as resposible developers would use is:

 <meta name="viewport" content="width=device-width, initial-scale=1">

For the same reason we might consider using relative units for fonts and padding rather than fixed pixels.

body {
 font-size: 1em;  //16px
 ...
}
	
h1 {
 font-size: 2.25em;  //36px
 padding: 1.25em 0; // 20px
}

This way when a user changes browser font size, our website will response immediately and, what’s important, proportionally. You can help yourself by storing font sizes as sass variables in one place and use them whenever needed.

How can we take advantage of default browser behavior as developers?

–>check it out is your website trendy<–

Elements roles in accessibility

Let’s consider simple navigation elements. First we’ll take a look at one of possible implementations in pure html:


&lt;div class="navigation&gt;
  &lt;a href="/home" class="navigation__item" title=”home”&gt;Home&lt;/a&gt;
  &lt;a href="/about" class="navigation__item" title=”about”&gt;About&lt;/a&gt;
  &lt;a href="/contact" class="navigation__item" title=”contact”&gt;Contact&lt;/a&gt;
&lt;/div&gt;

Seems fairly convincing? Maybe, but there are several problems.

`<div>` element which plays content wrapper is semantically neutral and that means it doesn’t carry any information of its purpose.  So maybe add ARIA `role=”navigation”` attribute? We could, but in instead we’ll take advantage of `<nav>` element which has its role set to navigation as default.

*This fragment needs a little explanation. You may find examples across internet that introduce using `<nav>` and `role=”navigation”` at the same time; the reason for this is that some older browsers did not implement HTML5 elements like `<nav>`, `<main>`, `<article>`, so they have no idea what their purpose is. Nowadays this problem nearly doesn’t exist as modern browsers link those elements with their roles and screen readers also understand them, even when a browser does not. [To make things clearer (or not).](http://alistapart.com/column/wai-finding-with-aria-landmark-roles)*

We made some changes, but we can do better. Let’s wrap our links into  `<ul>`


&lt;nav class="navigation&gt;

&lt;ul&gt;

&lt;li&gt;&lt;a href="/home" class="navigation__item" title="home"&gt;Home&lt;/a&gt;&lt;/li&gt;


&lt;li&gt;&lt;a href="/about" class="navigation__item" title="about"&gt;About&lt;/a&gt;&lt;/li&gt;


&lt;li&gt;&lt;a href="/contact" class="navigation__item" title="contact"&gt;Contact&lt;/a&gt;&lt;/li&gt;

  &lt;/ul&gt;

&lt;/nav&gt;

Now, we created semantic, hierarchical element and certainly more users will use it easier.

When css fails to load, we’ll still see a familiar list with black dots which resembles every other menu. Beside that, a screen readers’ user will not only hear “Navigation element”, but also a “List of five, first items ‘Home'”, which is exactly the information they need and the information they would never hear if we have chosen our first navigation attempt.

**Tip:** you can actually find out yourself what experience the screen readers’ users have. If you are using windows you can download [NVaccess](http://www.nvaccess.org/) screen reader for free. Mac users might use VoiceOver which is a built-in tool.

–>Find out other tips useful in designing a website<–

The principle of taking advantage of html elements that have a explicitly defined role like `<nav>`, `<button>` and `<ul>`  helps us built accessible interfaces effortless and fast.

Visual experience

Can you see it?

According to [National Eye Institute](https://nei.nih.gov/health/color_blindness/facts_about) 8% of men and 0.5% of women are color blind. That’s a decent number of people whose UI experience might be distorted. However, there are projects helping us deal with this problem such as [Open Color project](https://yeun.github.io/open-color/), which is a set of basic colors that look different in the deuteranopia and protanopia mode.

Beside color itself, we should also be aware of the contrast level, especially for text and background. Just recall when you last used a laptop with a glossy screen or an ATM on a sunny day. And yes, that’s the moment when you realize not only people with disabilities will benefit as some like to think about accessibility.

Check it out: 7 trends in Mobile

Follow the pattern

Basically, when we say a UI element is accessible it also means it’s somehow familiar to our user. While visiting website we assume that the menu is on top, main content is placed in the center and the green button probably encourages us to sign in or call another action. We *know* how a website works, because we have certain image of it in our minds, which helps us find each UI element in place that we *assume* it should be and make the whole process painless.

Following patterns doesn’t necessary mean killing creativity.  Just build your custom experience on top of that, making a website visually awesome, but still not causing any headaches to its users.

Parallel way

I think that the key thing is to give a user explicit information by using different means eg. text along with a symbol. As our colleague wrote in [“Are hamburgers any good?”](http://blog.primemodule.com/are-hamburgers-any-good/), simply adding a label to a hamburger symbol makes it much more accessible for older people not so familiar with that icon. And by “giving the same information” I don’t mean exactly the same experience, because it is simply impossible. Point is that even though someone can’t see that selected item changing its background color, she still knows what happened, because it also got a border around it.

 accessibility

Enhance your workflow

Creating accessible user interface takes some time to thinking about and test it, but keep in mind that the more people there are painlessly using a website, the more successful we are as developers. In this article we covered only a part of good practices and tips which may encourage you to do further research. In the Useful links section, you’ll find some interesting materials, which will help you immerse deeply in the field of accessibility.

Useful links

a11yproject.com/checklist.html

alistapart.com/column/wai-finding-with-aria-landmark-roles

webaim.org/

 

SIMILAR ARTICLES

Zbyszek Matysek

Leave a Reply

Your email address will not be published. Required fields are marked *