Web Accessibility, an… Intro?

I wanted to get some basic info on accessibility-related codes. So far, the W3CSchool has very simple and clean introduction for all the HTML and CSS that I look up, I did a simple google for ARIA and W3C. I got directed to the W3.org pages instead.

Wow. It’s a lot more reading than I expected…

As much as I love to read through the site, I am already reading Adaptive Web Design, and my web portfolio need to finish quicker than I could read both the book and the W3.org. So, base on my existing knowledge of accessibility from previous reading, Meetups, and  conversations, I searched specifically on items that I know and wish to implement on my site. Below are the basics that I have gathered so far. Remember that I am still new to it, so let me know if I got something wrong:

There are many type of disability, and it is a lot more common than one think. An elder with aging eyesight may have problem seeing the screen – but so can people with eye infection, mobile users, and even a person going through allergy attacks.

While I have forgotten the actual terms, state of disability can be described into 3 kinds that I call Permanent, Temporary, and Situational. Very often, when people talk about disability, their first thought is permanent ones, but it is important to understand how accessibility design influence and benefits those with temporary and situational disability – especially if you deal with a client. Temporary disability happens for a short period of time, some examples are people who are healing from a hand injury or have an eye infection. Situational disability are disability caused by current events, such as reading a screen under glaring sun or a low wifi connection. Not every client can relate to those with permanent disability and see the financial benefit – but if you accord for temporary and situational? That’s everyone. Improve site traffic brings up profits, and what business don’t want that? That’s not even including the fact that a clean, accessible design are often good for SEO.

Similar to how a ramp may have been originally intended for wheelchair accessibility has now become the to-go for baby-carrier, bicyclist, people using walker, and other elderly and injured people with mobility issues, a feature designed for one disability in mind can benefit many others. However, no design can 100% account for every single disability out there, for we are all unique. We can, however, account for the most common ones, and offer a graceful fallback.

The design of a website that is universally accessible should start from the beginning of design. It’s not just about adding some additional codes in the end – it should not be treated as an add-on, but as an integrated best-practice. The practice of designing with the goal to reach the widest amount of audience – incorporating practices such as accessibility, responsive design, browser support, and graceful degradation – is known as Progressive Enhancement. Though I am going to focus on accessibility here.

Firstly, consider your color scheme. There is color contrast: a well-contrasted website helps various individuals, such those with Diabetic retinopathy (which cause darken patches), Cataract (causes cloudy vision), and – for many of us – those reading the screen in glaring sunlight. According to W3C, the color contrast ratio of a website should be between at least 3:1 to 4.5:1, depending on the situation:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

“Contrast (Minimum) — Level AA” at W3C.org

There are various web resources where the color can be input and the site would calculate the ratio. During a Meetup I attended, Accessibility for WordPress Developers, presented by Ozzy Rodriguez, he suggested that developer can do a quick check by wearing sunglasses. I have also read that tracing paper can be used – though I am not if that works well, since I know from personal experience there are so many shades – when I studied in architecture and was doing floor plans, we have them in yellow!

Rodriguez also talked about color contrast and visibility in term of link, which causes me to change some of my site design. People tends to associate blue and underlined as active links – but many designers hates that because it doesn’t match the overall color scheme, and well, it’s boring. He suggested if a different design is desired, try to do it in a way that will still make it obvious it is a link. In my case, most of my link use burned orange colored text and dotted underline that changes to brown text and dashed underlined.

Then there is color-blindness – which by the way, can be inherited or be a side effect of medication. For that, avoid combining red and green (yes, the Christmas color), as well as purple and blue, since they are difficult to distinguish. Of course, if the viewer have Achromatopsia, there’s not much you can do in term of avoiding color matches – this typically means the viewer sees everything in black and shades of grey. That’s where color contrast is important.

In addition to color choices and contrast, another element to watch for is flashing animations, which can endanger people with photo-sensitivity – the flashing can actually trigger seizures. A memorable news I still remember watching  happened on December 16, 1997. A new Pokemon episode was aired in Japan. It was about Porygon, the first Pokemon to exist in cyberspace. The episode will never be broadcast again – 685 people were taken to hospitals that day (No, I do not know the number by heart. That’s Wikipedia.). The intense flashing of light and color triggered a mass scale of seizure due to photo-sensitivity – so intense that some of the patients got the seizure because they saw the news’s rebroadcast of the scene. Thankfully, fast flashes are not usually used in web design in the first place, but if you do use it, remember to stop by W3C for some guideline.

Secondly, let’s go site structure. Two groups that I have seen most writings about are people who uses screen readers and people who navigate using only a keyboard. In this case, both placement of the actual html tags and the use of semantic tags are important. Some of you whom are reading about accessibility may have heard ARIA, Accessible Rich Internet Applications, which are tag attributes that can aid in site accessibility.

When planning the structure, think about how a user may get to the content if they have a screen reader reading the site to them or have a devices that tabs through each element. Neither group would like to go through a bunch of supplementary contents before getting to the main content. As the saying goes, “Get to the main point already!”

Use semantic tag like <main> since many accessibility tools allows users to skip to those tags. In addition, semantic tags are shorter, cleaner, and better for code maintenance. I mean, what do want to read? <main></main> or <div id=”main” role=”main”>? And which loads faster when use on a large scale? Semantic tags are also informative for screen reader users. For example, during the Meetup I mentioned earlier, I learned that the <h1> – <h7> tags is not just good in term of code maintenance, it also let the screen reader know which content is more important. The general rules of thumbs is to use semantic tags if they are available.

Most semantic tags from HTML4 are accessibility supported, but the newer ones from HTML5 may not be – such as nav and header. In those case, it’s time to use ARIA, such as <header role=”banner”>. W3C have a list of available ARIA role, while Paciello Group have a great article on the reason of using ARIA with HTML5 semantic tags, plus a list indicting which tags are accessibility supported.

In general, in term of ARIA roles, most site should at least have banner (often with the header tag), navigation (often with the header tag), main (often with the tag that holds the main content), and contentInfo (often with the footer) roles. Since those roles defines areas of the site, they belong to a group of ARIA role call ARIA landmark – which includes application, complementary, form, and search. For roles, in addition to landmark – which defines a region – there is abstract, widget, and document structure roles.

In addition to planning about how users initially get to the content and the use of ARIA landmark, developer should also plan about changing elements like the use of Ajax. If a top page element is change, how do a user get back up? How do a user who can’t see even know about the change? This confusion can be avoided by better structure planning and using ARIA, which brings us to the third point.

Thirdly, the tags and attributes. Properly placed attributes causes less confusion when viewer is listening to the reader. In addition to roles, there are states and properties. Note that there are a lot of different states and properties, I am only going to the ones I encountered the most.

Two commonly known properties are label and labelledby. Those are mainly for element names that reader will read aloud (roles do that too, but as mentioned earlier, roles also aids in clean site structure and better navigation). If the label text is not visible, use ARIA label. If the text is visible, use labelledby. Note that if you are creating a form with actual <label> tag, ARIA will override that. A good site to look up further detail on this is WebAIM.

States are typically use for elements that will change. If you are looking into accessibility issues with JavaScript and Ajax, you will hear discussion about ARIA states. Better yet, look into ARIA Live Region. To put it in summary, imagine if Ajax is applied to an input form. A reader goes through the site in order. If Ajax changes an element and indicates a submission error, the reader is not alerted to it, and it leaves them in confusion. This can be avoided by the combination of placing error message below the input box and using appropriate ARIA features. A quick, very brief blog post I found is Accessible forms with ARIA live regions by tink, and an example for input error with ARIA role=alert is provided by W3C – though you really do need to do a bit of research for this one.

Fourthly, one should consider content. Size of text is an obvious one – please don’t put your text below 10px. Beginning designer will try to put their text in odd sizes and font to look “cool”. Don’t. People will have to enlarge it, which distorts your design and irritates them. Small size and odd font is to be handle with care, especially if you are just starting. On that note, make sure that enlarging text wouldn’t destroy your content (such as having the text disappear once it goes past border). They also applies to shrink screen – what happens to your site when your user view your site on a mobile phone? Avoid situations where users can only access your site on large screens, especially if you are dealing with community of elderly and low-income. Contrary to what some people think, those people do have and use smart phone – and in some cases, that’s all they have. No laptop. No desktop.

Attention should also be placed for multimedia. When multimedia first come into use, there were plenty of sites that would auto play musics and video, which is annoying as… *cough* annoying, really annoying. I can’t imagine the trouble of keyboard-only or screen reader users trying to get to the stop button. I initially installed NoScript precisely to stop Google’s autosearch and those pesky autoplay. Those features are even worst now because people use mobile devices, which has a data plan that can be blown out by those medias completely on accident. It is also problematic for those with hearing problem  – if they can’t hear, they don’t know it is playing. They wouldn’t know what is slowing down their connection or killing their data. Also, if a person needed information from those media, how do they access it? Make you multimedia play on demand and provide captions. Remember to tag them properly, so people with screen reader wouldn’t be surprise.

Hmm… I was planning to do just a brief summary to organize my thoughts, since I know so little about web accessibility, but this has turned into a two thousand word essay, and I not even in college! I think I will stop for now.

To be continue on when I learn more!