Click here to Skip to main content
15,395,181 members
Articles / Web Development / HTML
Posted 6 Jun 2018


4 bookmarked

Selected Web Accessibility Tips

Rate me:
Please Sign up or sign in to vote.
1.90/5 (3 votes)
6 Jun 2018CPOL9 min read
Briefly discussing web accessibility in general. Stressing a few prime points/tips that are easy to use and always good to follow. Suggesting to start using easy to understand and remember "rules of thumb".


First of all, this is just a short tip article. So, it is tipping coders about full size sources and legal documents explaining deeply general and Web accessibility, which both, in short, have the following goal [1]: "... to make sure that people with disabilities can have an equal opportunity to participate in programs, services, and activities".

Good starting sources are [1-5] and more advanced sources are [6-13].

Although accessibility requirements are strictly regulated in the U.S.A., keep in mind that according to [4]: "there is no such thing as «an accessible web site per ADA standards»". In other words, there is no a perfect website, and there is no a harsh control yet.


To understand what is regulated in the U.S.A. in general -- read the beginning of the first page of [6]. Just read titles of chapters and sub-chapters 4.1-4.37. Note: usually, only state and city institutions need to comply with these requirements. At the same time, some private businesses indirectly forced to comply too, e.g., hotels, restaurants, etc.

Many of these regulations are familiar to all residents and visitors of the U.S.A., especially on the streets (e.g., cut curbs), outside the buildings and within the buildings (e.g., ramps along the stares, elevators and restrooms fitting wheelchairs, etc.). But I've seen none of them in central and western Europe, also in Canada, Mexico, Brazil.

A different situation is with Web accessibility, and more general -- with digital documents. I.e., governmental organizations in the United States are forced to support requirements, but all other can ignore them. Sort of. Up to the next lawsuit? See "Section 508 enforcement" in [7].

At the same time, as it is stressed in [5], Web accessibility efforts are spreading worldwide:

"With the Internet becoming a more important part of society throughout the world, many countries are recognizing and acting upon the need to ensure access to the Web for people with disabilities".

The main subject here is a set of color requirements to comply to.

The prime goal of this tip article is to encourage all coders to start using easy to understand and remember "rules of thumb" and tips. It will make their pages and other digital documents more accessible.

Success Criteria

Requirements of the Web Content Accessibility Guidelines (WCAG) 2.0 (called "Success Criteria"), in short, are clearly formulated in [2], and here they are presented "as is" below.

So, Web content should be:



  • Provide text alternatives for non-text content.
  • Provide captions and other alternatives for multimedia.
  • Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
  • Make it easier for users to see and hear content.


  • Make all functionality available from a keyboard.
  • Give users enough time to read and use content.
  • Do not use content that causes seizures.
  • Help users navigate and find content.


  • Make text readable and understandable.
  • Make content appear and operate in predictable ways.
  • Help users avoid and correct mistakes.


  • Maximize compatibility with current and future user tools.

Color requirements

Conformance to requirements has 3 levels [9]:

"In order to meet the needs of different groups and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest)."

Our goal here is to deal with level AA. One of the main color requirements of any level is to support an appropriate to the level color contrast ratio. And the latter is defined as following [9]:
    (L1 + 0.05) / (L2 + 0.05), where
    L1 is the relative luminance of the lighter of the colors, and
    L2 is the relative luminance of the darker of the colors.

This definition will be simplified here, because black or very dark colors are used and accepted by publishers mostly for foreground (FG), but not for background (BG). So, instead of calculation, - it is recommended using tips, rules of thumb and tools discussed below. It's more simple to think about ratio as it was set between BG and FG. In other words:

TIP #1: If any tool is determined that a ratio is "bad" for your level, then you need to use brighter BG and/or darker FG.

According to [14]: "All modern browsers support ... 140 color names". Although there are very good sources for colors used in HTML and JavaScripts [14,15], additional "MyFaveColors" page is attached in the zip file.

Why would coder need another page with colors? A simple answer is: "It's always more convenient for me! I hope you will use it too." I'm sure, you know that many languages and tools have their own naming rules. Also, sometimes, "darkred" color in different tools is different too.

Here are some samples:

  • Even very close languages like HTML, HTML5, CSS and JavaScript have different rules. E.g., capital letters allowed and not allowed, also spaces are not allowed.
  • R and gnuplot have their own rules. E.g., spaces are allowed in R, but capital letters are not.
  • PARI/GP has very special rules.
  • Rules of many other languages vary too.

Do not be confused while using very good and flexible Color Converter [16]. It allows you to use both capital and small letters, spaces. But not all languages listed above will allow you to do it.

Also, it is more reliable if coder would be copy/pasting listed in the offered page names (or hex-codes). Plus, it would be OK for many languages and tools.

Of course, the experienced coder would have HTML fragments presenting <select> tags with option lists for favorite colors. Find a few samples in the "generator" page in [17].

Another sample: sometimes coder needs to create an array of color names. See such sample in [18].

Tips from publishers

Don't be surprised when you discover that some publishers allow only limited predefined set of colors [12].

There are some objects listed in [8] that are simply bad for some users (highlighted here):

TIP #2: "because of the potentially serious nature of seizures, developers should be extra careful to avoid any graphics, animations, movies, or other objects which have strobing, flickering, or flashing effects. Developers should also avoid graphics which may induce nausea or dizziness, or that may be distracting."

Let's continue with 2 tips from [12,13]:

TIP #3: "The most accessible approach would be to ensure that your [using colors] article is still readable when printed in greyscale."
TIP #4: "To ensure that you are using the most accessible colors, ACM recommends that you use tools like "Color Contrast Checker" [19] and "WAVE" [20].

Here are a few tips and "Rules of Thumb" from my experience, and they are related not only to colors:

TIP #5: Color is fading as result of any kind of scaling. It means: better plot and show a smaller size of the figure on small canvas if it's possible. This helps to avoid to scale down your image later, e.g., to fit a page.

Rule #1: Do not use black or any dark BG.

Rule #2: Use any really dark colors for FG and white or "extra" bright matching BG. This will guarantee acceptable contrast requirements.

Rule #3: Practically, almost any color name with "dark" prefix is suitable for FG.

Rule #4: If there is an animated gif (or equivalent element) it should start animation after clicking (or other action) and stop after the first time animation was completed.

Rule #5: Always use HTML tags and tag elements like following: alt, caption, label, etc., filling them with meaningful text.

Rule #6: Do not use unrelated sound effects.

Remark: Wikipedia has many pages violating "Rule #4", e.g., [21] has 6 images performing animation simultaneously and infinitely. And this is very disruptive even for a regular user.


There are may handy tools [16,19,20]. All 3 are recommended to you.

As a sample, I've tested my article [22] using "WAVE" [20]:


Here is a result:

WAVE has detected the following:

  • 41 Errors
  • 62 Alerts
  • 37 Features
  • 55 Structural Elements
  • 7 HTML5 and ARIA
  • 64 Contrast Errors


Panel Options

  • DETAILS: A listing of all the WAVE icons in your page.
  • DOCUMENTATION: Explanation of the WAVE icons and how you can make your page more accessible.
  • OUTLINE: The heading structure of the web page.

It should be stressed:

  • None of the mine images is marked as inaccessible due to bad contrast! LOL So, my old habits work!
  • All errors are related to Code Project formatting, and they marked as "bad accessibility", e.g.:
    • Chapter titles/subtitle and another orange on white text.
    • Any white text on orange.
    • Other CP images, especially from ads.

Color Contrast Checker [19] is pretty flexible. All you need to know is foreground and background color in RGB hexadecimal format and which WCAG 2.0 level is required. In most cases AA level is OK. But check [9] if you need to comply strictly.


All these easy to understand and use "rules of thumb" and tips will make your pages and other digital documents more accessible, and using them require minimal efforts. This is just a tiny step to improve accessibility, but it is very awarding step for all of us.

Final tip:

TIP #6: Simple tags like <br>, <b>, etc., are now allowed in HTML, but still are not allowed in XML.

Please understand that CP publishing wizard would be difficult to upgrade. So, when it "improves" your HTML article (actually: smashes, crashes, spamming it with HTML equivalents, etc.), please appreciate it, and just smile and say: "Thank you". It also means that in your own websites you can use these old simple tags.


  1. WebAIM (2013) United States Laws. URL:
  2. W3C (2011) How to Meet WCAG 2 (Quick Reference). URL:
  3. WebAIM (2018) Introduction to Web Accessibility URL:
  4. WebAIM (2013) United States Laws. Introduction to US Laws URL:
  5. WebAIM (2018) World Laws. Introduction to Laws Throughout the World URL:
  6. United States Access Board (2002) ADA Accessibility Guidelines (ADAAG). URL:
  7. WebAIM (2013) United States Laws. Overview of the Rehabilitation Act of 1973 (Sections 504 and 508) URL:
  8. WebAIM (2018) Seizure Disorders URL:
  9. W3C Recommendation (2008) Web Content Accessibility Guidelines (WCAG) 2.0. URL:
  10. Knowbility (2018) Accessibility training and education URL:
  11. Wikipedia (2018) Knowbility URL:
  12. Boris Veytsman (2018) LATEX Class for Association for Computing Machinery. v1.50. URL:
  13. ACM (2017) 2017 ACM Master Article Template. URL:
  14. w3schools (2018) HTML Color Names URL:
  15. mozilla (2018) CSS Color URL:
  16. (2018) Color Converter
  17. Voevudko, A.E. (2018) Gearographic Curves - Part 1. Code Project.
  18. Voevudko, A.E. (2017) Generating Random Voronoi Diagrams. Code Project.
  19. WebAIM (2017) Color Contrast Checker. URL:
  20. WebAIM (2018) WAVE - web accessibility evaluation tool URL:
  21. Wikipedia (2018) Sierpinski triangle URL:
  22. Voevudko, A.E. (2017) A Few Approaches to Generating Fractal Images in R. Code Project.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Voevudko A. E., Ph.D.
United States United States
I've started programming in a machine code and an assembly language for IBM 370 mainframe, and later programmed in many other languages, including, of course, C/C++/C# and ASP/

I've created many system automation tools and websites for companies and universities.
In addition, I've always been a scientist interested in Computer Science, NT, AI, etc.

Now I'm using mainly scripting languages for NT small problems and computer graphics.

Comments and Discussions

-- There are no messages in this forum --