We’ve put together a list of ten web accessibility guidelines to make sure your site is accessible to anyone, including people with disabilities.

Tim Berners-Lee, the chairman of the W3C, has said that “the power of the web lies in its universality”. As people who make websites for a living, it’s our responsibility to make them accessible to everyone. Web accessibility may seem like a daunting task in a paper, but it’s actually easier than it sounds.

We have designed these ten rules to ensure that all websites are universal.

These guidelines not only help screen readers, but also improve the browsing experience when the connection is slow. We’ve put these guidelines in order of implementation to give you an idea of how much time and effort you might spend in the process. Before you feel the rewards, take our word for it: this article is worth a read!

Let’s start with the first thing:

What is Web Accessibility?

According to W3C standards, web accessibility means that anyone can feel, understand, browse, interact with, or contribute to the Web. In other words, Internet accessibility includes all the conditions that affect Internet access, including visual, auditory, physical, verbal, cognitive and neurological impairments.

You can find a ton of content on the Web on this topic, and if you’re interested, you really should take a closer look at the Web Accessibility Initiative (WAI).

Without further ado, here are the ten rules.

1. Independent of color value (about 45 minutes)

Color is a powerful tool, and we often use colors to express or communicate our emotions. However, we should not put too much faith in what color can tell the user. Why is that? For example, most people know that green means right and red means wrong, but what if we only used color to represent this information?

Color blindness is a very common visual disorder. It affects about 4.5% of the world’s population (even more than IE11 users, you know…). .

If we were to tell the user whether the input was correct or not by color alone, the 4.5 percent of the colorblind population would not be able to get this information.

Color can aid in error messages, but you should never use color alone. In order to ensure that all users can get the prompt information correctly, we should add corresponding labels or ICONS to indicate whether the input information is correct or not.

An interesting solution is provided by Caniuse.com, which provides a palette way to display the corresponding compatibility list.

Ideally, you should check at design time to see if the color contrast meets the requirements, so make sure you and your design team have the right tools to check. We recommend the Stark Plugin for Sketch to check if your design meets accessibility requirements.

2. Do not disable zooming behavior (about five minutes)

In this age of adaptive design, we make mistakes that defy adaptability.

A common mistake is to use maximum-scale=1.0, because it disables zooming of web pages on mobile devices.

Astigmatism affects 30 to 60 percent of adults in Europe and Asia, but vague content affects people of all ages and nationalities (hi, mom, I’m talking to you!). .

Allowing web pages to zoom in is not only another WCAG guideline, but also a tool to simplify the daily lives of these people. So the next time you set up a site, think of users like my mom who have impaired vision and can’t see clearly.

In addition to allowing users to zoom in freely on mobile devices, be aware that when a desktop browser zoomed in 200%, your layout would still look good.

3. Relearn Alt attributes (about 45 minutes)

No matter how long you’ve been developing your site, you may still be surprised to learn of these famous but mysterious hints about Alt attributes.

  1. Alt is mandatory for every IMG tag, but the empty Alt attribute is still valid. If an image is decorative or you don’t need to know the content, just use italt=""That’s it.
  2. The screen reader tells the user that the tag is an image, so Alt doesn’t need extra information, such as “Picture of,” to just say what the image is.
  3. The function of the image is as important as its meaning: if your logo image links directly to the site’s Home Page, its Alt text should be “Home Page” instead of “LOGO.”
  4. Alt’s alternative text is not just for accessibility. Sometimes, users with slow data connections disable images for a faster browsing experience. So, every time you write an Alt attribute to an image, remember that there is still such a user!

However, not every image on your site is written with an IMG tag, right? You might also use one or two SVG images, or have all your ICONS in SVG.

How can we make SVG accessible? Fortunately, the Extensible Vector Graphics Standard already covers this. To describe this vector, there are both short description tags

and long description tags

.
 

<symbol ID ="langIcon"> <title>Language Icon</title> <desc>Longer description</desc> <path D ="M0 2c6.47 2 2 6.48 2 12s4.47 10 9.99 0h24v24H0z" /> </symbol>Copy the code

4. Subtitle and captions

This is probably one of the most difficult standards for WCAG to implement, not that the technical implementation is difficult, but that it is time-consuming. To accomplish this, there are several ways:

  1. Take YouTube. When you upload a video, you can choose to turn off the instructions. This content is automatically generated, but may not be accurate in some cases. Language, background noise, and the speaker’s accent can all affect the accuracy of the content. But in general, it’s easy to implement for the most part, and abstracts for most English videos work fine.

  2. If we go for 100% accuracy, YouTube is not as reliable, so we either write our own summaries or get a third party to do them. YouTube will probably use the most common subtitle formats, (.srt,.sub,.sbv), and also allow us to fill in captions on the platform; If you don’t know how to use captioning software, this feature is very handy, but we can also ask the community to help translate content without having to authorize an account.

  3. But maybe you don’t want to use YouTube as a platform. Maybe you just use HTML5 video on your own server. Don’t worry! HTML5 also has tags, so you can easily add several text captions and caption files, very similar to your usual WebVTT format.

<video controls> <source src="movie.mp4" type="video/mp4"> <track label="English Captions" kind="captions" srclang="eN" SRC ="captions.vtt" default> <track label="Subtitulos en espanol "kind="captions" srclang="es" SRC ="subs.vtt"> </video>Copy the code

5. Semantics = Accessibility (about 45 minutes)

Do you remember the font tag? I hope you don’t remember, because it was a dark time.

Although it is now widely accepted, semantic support is not inherent in HTML5. Semantic support has been around since the first HTML pages, and it has improved considerably since then. The HTML5 standard introduces new semantic tags for everyday use.

That’s great, but isn’t semantics just for SEO?

Not really. When you consciously choose a tag over a link, you have deliberately changed the meaning of the element, provided layers, and created a tree of information on the page.

Screen-reading software doesn’t miss this. In fact, semantic information is one of the most useful tools.

Remember that with great power comes great responsibility, so be sure to use the right semantic tag for each element, from the H1 tag to the brand-new main tag.

6. Use correct markers (about 30 minutes)

And then there are some other things that I want to discuss with you, the error-prone and slightly controversial parts.

Time vs. Datetime

The time element can be in a variety of formats, such as the time zone format in ISO8601, or the length of time. Datetime is one of the optional attributes that help display the content of the time representation. Let’s look at an example:

<time>14:54</time> Hours and minutes <time>2018-06</time> Year and month <time>-03:00</time> Time zones <time>2h Argentina took place on <time datetime= "2016-08-07" >August 7th</time></p>Copy the code

Del and Ins

The web changes quickly, but don’t let the fear of too much change keep you from paying attention to detail. We can tag content with both the INS and DEL and Datetime attributes.

The INS element represents additional content added to the document:

<ul>
    <li><ins datetime="2017-08-02">Icecream</ins></li>
    <li>Candy</li>
    <li>Pasta</li>
</ul>
Copy the code

Del indicates the deleted content:

<ul>
    <li><del datetime="2017-06-05">Rewatch Harry Potter 8</del></li>
    <li><del datetime="2017-06-05">Cry because ____ dies.</del></li>
    <li><del datetime="2017-06-06">Write article</del></li>
    <li>Order room</li>
</ul>
Copy the code

Button vs. The label

Grab some popcorn. This is great. Which one should we use? Let’s see: a TAB usually represents a link to another page that is in the current window or has a new window open. However, this tag does not work when it triggers actions such as drop and drop menus or photo libraries. The button element is the right choice in these cases and is usually used with JavaScript.

The button tag is also often confused with input type=”button”, but the difference between the two usually depends on context (text, image text, or just text, etc.).

When using the button tag, you generally need to consider two things:

The first is whether the context of the button is clear enough (take a close “X” button for example). We must add an extra aria-label attribute to it to help the user understand what it does.

<button aria-label="Close">X</button>
Copy the code

Second, if you need to use a tag (such as a search box or a light box effect gallery), then you should use the A tag and javascript control effects rather than using the A tag alone. Image libraries often use a tag and href links so that browsers can handle click events if JS is disabled.

But…

7. Use the Role attribute if necessary (about 1 hour)

To tell screen readers that our link triggers an action and not a normal tag, we must add a role attribute with a value of “button”.

But beware!

When writing JavaScript, you should call functions not only when the user clicks, but also when the user presses the space bar. This is done because the user’s behavior is different when browsing with a keyboard than when clicking on a link with a mouse, and both methods should trigger the event correctly.

<a href="img/kitten.jpg" role="button" onclick="handleBtnClick(event)" onKeyPress="handleBtnKeyPress(event)">
    Button
</a>

function handleBtnClick(event) {        
    // Do something
}

function handleBtnKeyPress(event) {
    // Check to see if space or enter were pressed
    if (event.keyCode === 32 || event.keyCode === 13) {
        // Prevent the default action to stop scrolling when space is pressed
        event.preventDefault();
        // Do something
    }
}
Copy the code

More on this at MDN.

Keep in mind that aria attributes are not always necessary, except in the case of the example above, where you don’t have to follow this rule. HTML semantic elements have a default role, such as “navigation”, “link”, and so on. That is, role attributes need to be used only if the default values need to be changed.

8. Hidden Elements (approx. 1 hour)

HTML and CSS have methods for hiding elements. The table below should help you find the appropriate method to use.

methods Effect of the Read the screen software compatibility
CSS: visibility: hidden; The element is hidden from view, but its position remains unchanged (effect is similar to opacity: 0) Do not read General everywhere
CSS: display: none; Hide the element from both the view and the spatial flow, and the next element takes its place Do not read General everywhere
HTML5: hidden attribute And display: none; The same Do not read IE11+
Aria – hidden = “true” The content is visible, but ignored in assistive tools Do not read IE11+
CSS: .visuallyHidden class Elements are hidden in the view and in the flow Can be read General everywhere

If you want to hide the element in the view, but the screen reader can still find the element, then the last method is appropriate.

This works well for tags or links that require tweaking of content. The visuallyHidden pseudo-class is one of those CSS types that you can easily bookmark for use in a variety of projects. You can change your name if you want, like.Potterscloak, FYI.

9. Follow web accessibility standards (approximately 30 minutes per week)

Web accessibility is hard to achieve, so there are standards and specifications to guide you.

At this point, you may be asking: How do these specifications work and when should we use them? What is the difference between CSS rules display: None and visibility:hidden?

The W3C standards and WCAG specifications may be boring to read at first, but they are actually very reliable and educational. You should check it out and drown yourself in a sea of information. I’m sure you’ll also discover a lot of code practices you’ve never used before.

10. Audit and review (approximately 3 hours)

If you know these things, put them to the test. Here are some great tools for reviewing web accessibility.

  • ChromeVox: For Mac and Windows users, you can test your web site with this Chrome plugin.
  • Accessibility Developer Tools for Chrome: Another browser plugin that you can test daily.
  • Color Filter: This test is used to test whether the Color scheme of your website has an effect on people who are Color blind or colorblind.
  • W3C Validator: The official testing tool of the W3C to ensure that your HTML meets the requirements for web accessibility.
  • A11Y Compliance Platform: The Internet Accessibility Censorship Authority (BOIA) provides A graded report that Outlines how your site will score when tested according to some key points of WCAG A/AA.
  • WAVE: A web accessibility evaluation tool developed by WebAIM.

Aerolab’s experience with web accessibility features

We’ve been trying to make testing a daily work habit. Our next product should always aim to surpass the last. We do make mistakes, but we keep changing evolution, and we keep learning from challenges.

We want our products to always provide the best user experience, so we have made our products accessible from the very beginning.

“The road is long, I see no end, I will search high and low”, but we are glad to have chosen this road.

The home page below is an example of what we did for Xapo, so you can check how we did it according to accessibility standards.

The Xapo home page and store page meet the criteria 1, 3, 5, 6, 7, 9 mentioned earlier. Although we have not 100% met the requirements of 2 and 7, we have been working towards this direction

conclusion

Web accessibility is not that easy, but if you make it part of your daily routine (rather than a last minute checklist), implementation and testing will be a lot easier.

If you have any doubts, ask other developers directly for help, or do some research yourself. Here are some of my favorites: The A11y Project, A11y Wins, HTML5 Doctor and MDN.