blog

Web Accessibility: Why W3C Standards Are Often Ignored

The term du jour is web accessibility—in my opinion, one of the most frequently misunderstood and poorly applied aspects of web design. The common misconception is that accessibility is designed solely for disabled people. In fact, everyone benefits from accessible content, and your audience will increase by gaining access to accessible content on different platforms or in different ways, because they can use your content with fewer constraints.

Unfortunately, a lot of web developers do not make their content accessible and do not follow web accessibility guidelines; thus, many people experience unnecessary difficulties using their designs and enjoying content. In extreme cases, certain groups of users can’t use such a website effectively at all.

Building accessible content should be second nature to any developer, designer, or content creator, the same way the consideration of ramps, stairways, and lifts is to an architect designing a new building.

Let’s take a closer look at what’s behind the scenes and why so many developers seem to overlook web accessibility standards for no good reason.

1. What Does “Accessible Design” Mean?

Accessible content is content everyone can use. We don’t know all the aspects of how the users are accessing our content, so we need to design with accessibility in mind ahead of time.

As I highlighted earlier, this does not concern people with disabilities, accounting for about about 15% of the world’s population. In real life, users often end up not consuming content and interacting with devices in the exact same way as envisioned during development. Accessible content is also required for legal reasons in many jurisdictions. Read “Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization” for additional information on accessibility compliance.

Consider the following scenarios while thinking about accessible content for users that may be:

  • Unable to hear well. 360 million people worldwide have hearing disabilities. Audio content should have transcriptions and video should have captions.
  • Unable to see well. 285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision. Users that are visually impaired they use screen readers (that read the content using synthesized speech), refreshable braille displays (screen content appears on the braille display, and the user can navigate and interact with their device using the keys on the display) or high-contrast mode.
  • Affected by dyslexia. People with dyslexia find difficulty in reading and understanding content, especially, e.g., justified text or all caps.
  • Suffering from physical limitations. Not all people can use all devices. For example, navigation through the content must be available not only for mouse users, but also for users that can’t use a mouse.
  • Using mobile devices. Adapt your content for small screens. Allow the user to zoom or increase the font size.

2. How to Ensure Good Web Accessibility

People use very different ways of navigating and consuming content. There are users that need to be supported by additional software tools that helps them access content easier. These tools, known as assistive technologies, range from screen readers to touchscreens and head pointers.

However, your application and assistive technology need to talk to each other. Not everything that is written in HTML is fully understandable for assistive technologies. In order to help “translate” content from “technical language” to more human readable language, additional accessibility API standards have been created.

This basic web accessibility diagram should give you a better idea of how assistive technologies work.

To illustrate how it works, let’s look at a simple code example:
<a href="#” class=”button”>Delete</a>

This simple code, for people who use the screen reader, doesn’t mean much. It’s even misleading and reads only as a link with the text “Delete”. In order to help users to understand what kind of method is used to perform the action, we can use ARIA (Assistive Rich Internet Applications) attributes (specified at https://www.w3.org/TR/wai-aria/) to override the original role. We change the meaning of a link to a button by adding attribute role="button". In that way, screen readers will read it as a button, not a link. Which is more appropriate.

In short, attribute ARIA:

  • Gives or enhances semantics of non-semantic or other-semantic elements,
  • Ensures that dynamic (live) content is still accessible.
  • Provides the role to describe the type of defined widget (menu, tree item, slider, progress meter, etc.).
  • Provides the role to describe the structure of the web page (headings, regions, and tables).
  • Provides the state of the widgets (checked, has popup, etc.).
  • Provides properties for drag-and-drop that describe drag sources and drop targets.

What Is Accessibility in Web Design?

Whenever you design a content think about two things: how the content is perceivable and how it is operable. Let’s examine some examples to illustrate accessibility in web design.

Let’s say you are going to design a custom select dropdown element. Here are the things to consider while designing the element:

  • Mark different states: enabled, disabled, read-only.
  • Mark the element when it gets the focus/hover state.
  • Mark every option element when it gets focus/hover state.
  • Make sure the content is still readable when only the text is zoomed up to 200% level.
  • Make sure that there is enough contrast between the text and its background. It helps people with moderately low vision or on devices in extreme lighting conditions, e.g., exposed to direct sunlight or on a display with low brightness, to read the content.

Another example could be selecting a color to describe a state. Here are the things to consider while designing a section where the user will be able to pick up a color:

  • There are people that have difficulty distinguishing certain colors. So green doesn’t mean green for all your visitors. To fix it, add a description for every color that describes the purpose.
  • Mark each element when it gets the focus/hover state.
  • Make sure there is enough space between elements so that every element can be easily activated, e.g., on devices with a smaller viewport.

3. Accessibility Testing: Where to Begin?

There is no one way to check and be sure that web content is fully accessible. Multiple techniques need to be used in order to verify and fix the accessibility issues. You may start by defining issuessolutions, and priorities.

Defining issues

While working on accessibility issues, always try to create one ticket per problem with a clear title. This should simplify understanding the issue and help to define a priority.

Bad example: The user can’t use the keyboard on the page.

Good example: Unable to use keyboard navigation in the main menu.

The bad example leads to a case that will be quite difficult to close in a short time. Discussions on multiple topics might start in the comments section as well, as the ticket title is too generic.

The good example points exactly to the problem and focuses only on one thing: keyboard navigation in the main menu.

Prioritize Web Accessibility Issues

Priorities are important because they define which problems must be fixed first. For example, WCAG is divided by three conformance levels: A, AA, AAA, which means you should start from a minimum level A, but that doesn’t automatically mean that AA and AAA levels are merely “nice to have.” All of the levels are important, and it’s important not to prioritize assuming that level A alone is sufficient.

However, WCAG levels (or any other guidelines) might be quite difficult to understand sometimes and in order to simplify it a bit, you may also consider the following priority definitions:

  • Critical – Issues that prevent users from using an application. No workarounds available.
  • Major – Issues that make using an application difficult and/or disorienting, but don’t block a user’s ability to complete the operation.
  • Minor – Issues that are annoying but do not hamper use, or enhancements that could be made to the application.
  • Info – Does not adhere to best practices. General recommendations for improvements.

Solutions

None of the guidelines—by which I mean WCAG, Section 508 or ADA—will give you a straight solution in terms of technical code for how a specified problem should be fixed. They only define expected behavior. However, WCAG additionally has defined test procedures that should help to understand how to reproduce the issue and there is an Automated WCAG Monitoring community group, a W3C community with a focus on developing reliable rules for web accessibility testing, both automated and semi-automated.

An example for WCAG technique G4 (“Allowing the content to be paused and restarted from where it was paused”):

Test Procedure

On a page with moving or scrolling content,

  1. Use the mechanism provided in the web page or by the user agent to pause the moving or scrolling content.
  2. Check that the moving or scrolling has stopped and does not restart by itself.
  3. Use the mechanism provided to restart the moving content.
  4. Check that the movement or scrolling has resumed from the point where it was stopped.

Expected Results

No. 2 and No. 4 are true.

As we can see there are no technical solutions, but defined expected behavior. How web developer simplement it is up to them.

Web Accessibility Guidelines and W3C Standards

Following basic web standards should be your starting point:

  • The most common is the Web Content Accessibility Guidelines known as WCAG. WCAG 2.0 is “a stable, referenceable technical standard. It has 12 guidelines that are organized under 4 principles: perceivable, operable, understandable, and robust. For each guideline, there are testable success criteria, which are at three levels: A, AA, and AAA.”
  • Techniques for WCAG 2.0 is a comprehensive guide for web content authors.
  • W3C Media Accessibility User Requirements — This document presents the accessibility requirements users with disabilities have with respect to audio and video on the web.
  • Twenty-First Century Communications and Video Accessibility Act — The CVAA is divided into two broad titles or sections. Title I addresses communications access to make products and services using Broadband fully accessible to people with disabilities. Title II of the accessibility act breaks new ground to make it easier for people with disabilities to view video programming on television and the internet.
  • Section 508 — accessibility requirements for information and communication technology (ICT) that applies to all federal agencies when they develop, procure, maintain, or use electronic and information technology.
  • Website Accessibility under Title II of the Americans with Disabilities Act (ADA) — There, you’ll learn how the nondiscrimination requirements of Title II of the ADA apply to state and local government websites.

Related posts

7 Replies to “Web Accessibility: Why W3C Standards Are Often Ignored
  1. 加強優化面部輪廓,可被身體完全吸引,能自然地修飾面部輪廓 功效可長達24個月以上 JUVEDERM的特點: 效果立即可見 非永久性 非手術性 安全有效 效果自然 JUVEDERM獲歐盟(CE)及美國及藥物管理局(FDA)認證 首先及唯一獲得FDA認證在首次療程後能維持長達一年2-4功效 新世代專員Hylacross科技為產品帶來獨特的物理特質,包括凝聚力、支撐力及柔順度 8點提升 這是一套由全球著名醫學美容醫生Dr. Maurício de Maio,以JUVÉDERM®系列透明質酸產品為基礎而研發的面部優化療程,藉著簡單程序便達致面部優化效果,不需進行手術,減低風險。 此療程會根據病人的個別情況,重點針對面部8個最常因流失膠原蛋白及彈性纖維而凹陷的位置,再依據特定的順序,從顴骨至下巴位置配合JUVÉDERM®系列的透明質酸產品進行療程,從而改善這些位置的豐盈度及滑溜度,全面性優化面部輪廓。

    http://cosmedicbook.com/treatments/info/全港首部-Venus-Fiore閨密儀-RF射頻-私密緊緻療程

  2. 前額拉皮、抬眉手術、傳統前額拉皮、內視鏡前額拉皮、直接抬前額拉皮、改良式髮際線拉皮、五爪拉皮術、三爪拉皮術、八爪拉皮術、抬頭紋、三角眼等一些相關議題、似是而非或有爭議的事項的披露與討論。

    https://skinac.com/tag/配方

Leave a Reply