Coming Next: WCAG 2.2

Posted by Kim Krause Berg cre8pc    Updated

It is a myth that website accessibility is a once and done exercise. Similar to how SEO’s follow every Google algorithm update and chase the results to see what blew up, accessibility for websites and apps is also in a constant state of fluctuation.

In other words, you can’t make a change in your code and think it will last forever.

Computer devices change. Browsers change. Technology changes. Standards change. Rules, guidelines and laws change, in every state, province and country.

How business is conducted online changes too.

These changes are driven by me and you. Your children. Your families. Friends. Neighbors. Customers. Clients. Employees.

Accessibility Design Includes You (Sooner or Later)

Accessibility design is referred to as inclusive design because we not only must learn how to use the web, we may also need help to use it at all.

We grow older. We are unique. We are born with disabilities and sometimes develop them over the course of our lives. We break an arm, or hand or suffer from depression or a temporary emotional freak out from stress or an emergency.

We need our computers in different ways in those crazy moments and normal daily ones. It is out of this understanding and respect for you, that website accessibility testing is done. It is a not an automated quick fix by AI.

Because you are not robots.

WCAG 2.2

The first draft of WCAG 2.2 was made available on August 11. To get an idea of the work involved in changing accessibility guidelines, take a look at the comments at GitHub.

It is backwards compatible to WCAG 2.0 and WCAG 2.1. There are nine new success criteria in WCAG 2.2, which is expected to be officially adapted later this year.

New Success Criteria for WCAG 2.2

WCAG 3.0 is On Deck

It will NOT be backwards compatible. In fact, it is a do-over.

The WCAG3.0 August 27 Editor’s Draft can be read now.

“WCAG 3.0 uses a framework that allows it to address more disability needs than WCAG 2.X, as well as address publishing requirements and emerging technologies on the web such as web XR (augmented, virtual and mixed reality) and voice input. It will also provide non-normative information about the ways web technologies need to work with authoring tools, user agents, and assistive technologies.”

Fasten your seat belts.

Kim’s Notes June 10

Posted by Kim Krause Berg cre8pc    Updated

“Courts across the nation are split on what it means for a website to be considered a place of public accommodation under the ADA. The Ninth Circuit, discussed above, finds that the ADA applies to websites if there is a “nexus” between the website and the company’s “physical space” open to the public.

For example, in Earll v. eBay Inc., the Ninth Circuit concluded that eBay is not subject to the ADA because its services are not connected to any “actual physical place.” Courts in the Third, Sixth, and Eleventh Circuits share this view. However, courts in the First, Second, and Seventh Circuits have adopted a more expansive definition of a “place of public accommodation” encompassing more than actual physical structures.”

INSIGHT: Covid-19 Causing a Surge in E-Commerce—Is Your Website Accessible?

Dark Patterns

Posted by Kim Krause Berg cre8pc    Updated

Paul Boag has a nice series of articles and video on website conversions manipulative practices known as Dark Patterns.

Dark Patterns and Aggressive Persuasion – 3 Reasons to Avoid!

Kim’s Notes December 16, 2019

Posted by Kim Krause Berg cre8pc    Updated

Accessibility design begins at the start of a project.

Start thinking about all the types of people using the website. 1 billion people are disabled according to the Health Org. Add people who don’t identify as disabled, add people who experience temporary or situational disabilities, age, friends and family of people with disabilities = 7.7 billion

A11Y lead to audiobooks and video captions and other innovations.

It is too expensive to ignore A11Y. Political and health websites ignore inclusion at their own risk.

Kim’s Notes November 21, 2019

Posted by Kim Krause Berg cre8pc    Updated

When using images for text that describes an action the user takes, describe that action in the alt attribute text.

A logo alt can simply say the brand name. Do not stuff keywords in logo alt attributes.

Avoid putting navigation links in text. They may not resize properly and become unreadable when magnified.

Ads with text – put all the content in the image into the alt attribute.

The title attribute can be used to provide advisory information. It does not replace the alt attribute.


Screen reader users can navigate by iframes.

Each iframe needs a title for screen readers. <iframe title=”YouTube Video – Topic” src=”video.html”></iframe>


When adding video to a web page, you can link to the transcript below the video, or put the transcript in full below the video. If a lot of content, create a 400px div with scrollbar.

Audio descriptions are an audio track with a narrator explaining what is happening when there are gaps in the dialogue or other sounds of the movie.

Kim’s Notes November 20, 2019

Posted by Kim Krause Berg cre8pc    Updated

Blind people navigate web pages by scanning headings inside screen readers to quickly understand content and layout.

For example, in JAWS, the “H” key jumps from one heading to the next, reading them in sequential order, no matter what level the heading is (h1, h2, h3, etc.). The “1” Key jumps through all of the level 1 headings (<h1>). The “2” key jumps through all of the level 2 headings (<h2>), and so on.

One of the main reasons to start with <h1> at the beginning of the main content is because screen reader users may use keyboard shortcuts to navigate directly to the first <h1>, allowing them to jump directly to the main content of the web page

Screen reader users often navigate from link to link by using the tab key (or shift + tab to go backwards through links). In this way, only the link is read, not the rest of the sentence, so undefined links like “click here” or “more” are not helpful.

Links should not be empty. Screen readers may end up reading the link destination or some other piece of information (such as an image file name, if the only thing in a link is an image without alt text) if there is no text in the link. 

Link text (and alternate text for images, when used as links) describes the destination or purpose of the link. The link text should make sense out of context of the words around it.

The proper way to distinguish links from the surrounding text is to use a combination of color and a secondary method that provides a visual cue to the user. The simplest and recommended visual cue is to add an underline to the link text. Add a background color and border when the mouse hovers over it.

If color is the only method being used, it must provide at least a 3:1 contrast ratio to the surrounding text during all states, link, hover and visited.

Users with motor disabilities need large touch targets. Some people experience hand tremors or imprecise hand movements. Other people cannot use their fingers, and may use other body parts, such as their knuckles, elbow, or toes.

Touch targets to consider:

  • Links
  • Menus
  • Submit Buttons
  • Checkboxes
  • Radio buttons
  • Text input fields
  • Select fields (comboboxes)
  • Custom widget controls like media player buttons

For native apps:

  • On standard resolution devices, set the width to at least 44px (according to Apple’s recommendations) or 48px (according to Google’s recommendations). On Android, it’s best to use the 48px size, due to Android’s layout grid .
  • On devices with double the pixel density (such as Apple Retina screens), set the width to at least 88px-96px in terms of true screen dimensions.

On web pages:

  • Set the width to at least 44px in the CSS (Android’s 48px layout grid is less relevant on the web, but it doesn’t hurt to make touch targets larger). Standard resolution devices will render it at 44px and double density devices will interpolate the value and render it at the equivalent of 44px, even though the actual value will be 88px.

Links within the text should contain enough characters that the touch target will be at least 9.6mm wide.

The more common way of increasing the target area is by adding legitimate label text, using the <label> tag. When the <label> tag is properly applied, all of the text in the label is clickable, so whether users click on the text or the button, the button will be selected.

Don’t use background images or watermarks to convey information, because there is no way to provide alt text for background images.