Notes on Web Accessibility
Some quick ways to make your sites more inclusive
Web accessibility is not new. It has been around for almost 19 years, it was started by The Web Accessibility Initiative back in 1997. However, until today, it is still largely being ignored by most product designers and developers.
Furthermore, there are many misconceptions about accessibility which prevent people from making their efforts to embed it into their day-to-day work.
Is it really just about disability?
Not exactly.
One of the most common misconceptions of web accessibility is that it is only about disability. Accessibility is about making something that can be used by as many people as possible.
The realm of accessibility are:
- Environments
- Devices
- Elderly
- Cultural norms
- Impaired and cognitive abilities
- Languages
Just because a majority of your users do not have hearing difficulties does not mean that there isn’t any hearing impaired users out there who are using your sites.
Ways to make your sites more inclusive
We need to make sure the content that we put up on the internet is friendly for assertive applications and versatile enough to be read in as many ways as possible.
This post will attempt to touch on some web accessibility tips and describe their benefits and impact on users who are relying on assistive technology e.g. screen readers.
1. Doctype declaration
Typically, browsers are smart at reading HTML, however, without doctype declaration, it doesn’t understand which type of HTML it is looking at.
Having a correct doctype declaration allows the browser to treat the code within the page and render them correctly. On the other hand, using incorrect doctype could cause the browser to load the page in quirks mode where the page can look pretty different in each browser; as a result, disabled visitors will be unable to use/navigate the page at all.
<!DOCTYPE html>2. Define document language
Like the DOCTYPE declaration, you should identify the language of your website.
Defining the correct language of the website enables:
- Screen readers will pronounce the text correctly.
- Spell checkers know what language to use.
- Browser’s text rendering and styling.
- Accessible to millions of users who would otherwise be excluded due to language differences.
- SEO benefits (i.e. Google). More than 50% of Google users search in languages other than English.
<html lang="en"><html lang="fr">
If you’re writing in another language, look up your language code here. Language codes are not case-sensitive.
3. Allow pinch and zoom
Should users be allowed to pinch and zoom in a responsive web design?
The answer is yes.
According to a survey conducted by WebAIM (Web Accessibility in Mind), both a screen reader and a screen magnifier app were used by 23% of respondents respondents. Similarly, respondents said that they frequently used the browser zoom controls while surfing the web.(Source: http://webaim.org/projects/lowvisionsurvey/)
I’ve read that some sites disable pinch-zoom because they need to keep their ads visible. I strongly believe that it is our end users who should get the full control of how they want to view our designs.
Typically, pinch and zoom can be disabled by putting these,
<meta content=”width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=1;” name=”viewport”>or this…
<meta name=”viewport” content=”user-scalable=no” />However, please don’t do that. Blocking this behavior will hinder the basic of web accessibility. Moreover, the Web Content Accessibility Guidelines (WCAG 2) stated that sites must be scalable without assistive technology up to 200%.
So, here is what you should do instead,
<meta content=”width=device-width; initial-scale=1.0; maximum-scale=2.0; user-scalable=1;” name=”viewport”>and…
<meta name=”viewport” content=”user-scalable=YES” />
4. Use Progressive Enhancement approach
The Web is a vast world and people use it in different ways. We have users with disabilities, users who have low internet bandwidth and users who are on fast connections.
In spite of the fact that all of them use the web differently, they still have one shared goal—which is to access content and information.
In order to make sure that the site is accessible to anyone, anywhere and any circumstances, we can look to progressive enhancement concept.
Progressive Enhancement is a web design approach that place content as the core layer (with semantic HTML markup), followed by presentation layer (CSS) and the server-side scripting layer.
Having a well structured semantic HTML page allows screen readers to easily identify the page’s section and content If the site’s JS doesn’t load for some reason, it is OK, because browsers and screen readers are still able to render and read the content accordingly.
In summary, progressive enhancement ensures an accessible experience for sighted and screen reader users regardless of any situation.
5. Invisible labeling: ARIA-LABEL attribute
ARIA stands for ‘Accessible Rich Internet Applications’ and it is a set of attributes which can be added to any markup to make your website more accessible to people with disabilities such as hearing or visual impairment.
In this post, I will specifically talk about the aria-label attribute. It is putting a label to any HTML element. Some may ask, what about the ‘title attribute’? Well, title attribute is for your mouse cursor, that floating texts when you hover a link or object. However, aria-label does not behave that way, it is invisible and specially for screen reader applications.
Here is an example of a button code we would normally see,
<button type="button" class="close" data-dismiss="modal">×</button>Nothing seems unusual here. However, when a screen-reader detect this line of code. It will not read out: “Close button”, instead it will say “Multiplication button”! For visually impaired users, this experience would be a total failure.
To turn things around, we can attach aria-label to the <button> element:
<button type="button" class="close" data-dismiss="modal" aria-label="close">×</button>6. Regions and landmarks
ARIA roles (or “landmarks”) break the page into sections. Landmarks let all users know the different sections of a page.
It is useful for screen reader users to skip/jump between landmarks and navigate through a page.
With HTML 5, these designations are possible, using the new elements <header>, <nav>, <main> and <footer>. Similarly, ARIA roles also provides such attributes too, for example, role=”navigation”,role="main” and role=”footer”.
An typical example of ARIA roles might look something like this:
<nav role="navigation">
<ul>
<li><a href="/">home</a></li>
<li><a href="/about">about</a></li>
</ul>
</nav><main role="main">
<h1>This is the main content of the page</h1>
</main><footer role="contentinfo">
<p>Footer content here</p>
</footer>
In the example above, roles of navigation were put on the navigation list that contained the navigation links. For best practise, please provide both HTML 5 elements <nav> and ARIA landmarks role=”navigation” at the same time in the same element. Now, the screen reader will know which one is the navigation menu and present the options to the user accordingly.
“Good page organization means different things for sighted users, screen reader users, and screen magnifier users…one of the first options a screen reader will read is “skip to content”, this lets the users quickly skip the navigation area and go straight to the page content.” — Kara Pernice and Jakob Nielsen, (Usability Guidelines for Accessible Web Design, page 75)
It’s the right thing to do
I personally think that accessibility does not belong to a person to perform some evaluative tasks at the end of a project. It should be a priority of the entire team members. Everyone plays a part to be aware of the importance of accessibility and its best practises.
“For accessibility to become embedded as best practice in an organization, all team members have to understand the part they play in producing a product which everyone can use.” — Mark Palmer
Perhaps, during each project’s lifecycle, try to get everyone to discuss about accessibility practises, it can be during the design planning, content creation, development or even QA phases, that might be a good starting point.
If you have peers who are not yet familiar with accessibility, you can start by educating them about it. Show them how to use screen readers like JAWS, NVDA and ChromeVox. Get them to install and explore colorblind simulator apps too. If possible, distribute Web Accessibility Checklist(A11Y) and share it with the team.
The key here is to start small. Hopefully, the thinking about accessibility will gradually becomes their second nature.
— Teo Choong Ching
Resources
Feel free to check out other web accessibility resources here:
- WAVE Tool Chrome Extension
To check if your site is access-friendly, try this tool on your Chrome browser. Get WAVE tool. - W3C Web Accessibility Initiative (WAI-ARIA)
https://www.w3.org/WAI/intro/aria - A List Apart: Learning to be Accessible by Susan Robertso
http://alistapart.com/blog/post/learning-to-be-accessible - Heydon Pickering’s Inclusive Design Patterns
https://www.smashingmagazine.com/inclusive-design-patterns - Web Accessibility with Google
https://webaccessibility.withgoogle.com
“The goal of Web design is not merely to dazzle, but to deliver information to the widest audience possible.” — Steve Champeon (Inclusive Web Design for the Future, SXSW 2003)
