Category: WCAG

Overview

As you know, W3C released WCAG 3.0 first draft on the 21st of January 2021. The full form of WCAG also has been changed from web content accessibility guidelines to W3C accessibility guidelines. WCAG 3.0 does not talk web alone and it talks various technologies such as mobile, apps, PDF, ePub, voice input, smart watches, smart

TVs, VR and AR, and so on. unlike WCAG 2.x, WCAG 3.0 aims to be very simple language and cover a broader group of people with disabilities. The guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools. Working group also wants to update the guidelines on the regular basis in order to keep pace with constant technological change.

WCAG 3.0 is undergoing major changes especially in terms of it’s structure of the guidelines as well as conformance model. In the coming sections, we are going to discuss briefly what changes WCAG 3.0 is undergoing in terms of it’s structure as well as conformance

 

How are the guidelines are structured

The structure of the WCAG 3.0 is completely changed from WCAG 2.x series. There is no success criterion concept in 3.0 and there are new terms such as outcomes, methods, critical errors, functional categories, you would be hearing.

Guidelines

Guidelines are kind of same as WCAG 2.x series. Guidelines are high-level, plane-language and aimed at non-technical experts for easy understanding. Guidelines are more granular and easier to understand. Guidelines provide the solutions for the accessibility problems. The examples of guidelines are text alternative, clear words, captions, headings and structure, colour contrast. Guidelines are grouping of similar areas to test.

 

 

Outcomes

 

Each guideline contains one or more outcomes. Outcomes are the testable statements. Outcome is similar to success criteria in the 2.x series. Outcomes are measured with scoring but not pass fail. Outcomes are more user-need oriented instead of technology oriented. One of the examples for the outcome is text alternative available.

 

 

 

 

 

Functional categories

 

 

Functional categories are the group of disabilities. There are 14 disability types as part of functional categories. Each outcome relates to the one or more functional categories. For example, for text alternative available outcome, the functional categories are sensory- vision and visual, cognitive-learning, cognitive-memory, and so on.

 

 

Critical errors

Critical errors section is being expected to be revised after receiving the public feedback from the initial draft. As per the initial draft, Critical errors are nothing but a blocker or stopper for the user to access particular features. Critical errors include things like flashing content, audio without pause, keyboard trap. Outcomes may or may not have any critical errors. If outcomes have critical errors, then it would score very low. The scoring information related would be discussed in the next sections of this blog post.

 

Methods

Methods are kind of similar to techniques in the 2.x series. Methods are the ways to meet the outcomes. Outcome may have one or methods. Methods are the areas of concepts to test but methods are not tests though. For example; for text alternatives outcome, the methods are informative images, functional images, decorative images, images of text and so on. in addition, methods vary based on the technology. For example, testing PDF and VR is different from testing HTML.

 

 

 

How-to

How-to is similar to the understanding document of 2.x series. It provides the detailed explanation about guidelines.  it helps for developers, designers, new to accessibility experts in understanding the guidelines in-detail.

 

How is WCAG 3.0 tested?

 

There are 2 types of tests in the WCAG 3.0. one is atomic tests and other one is holistic tests.

Atomic tests

 

Atomic tests are nothing but every element is being tested at the code level. To put it simpler, they are the similar way that we are testing today in the 2.x series. Atomic tests include existing level A, AA, AAA of 2.x series. Atomic tests include both views and process. View is kind of web page. Process is something like flow that user has to follow in order to accomplish the task. Example of process is placing an order in the ecommerce site. Placing order includes the tasks such as searching for the item, adding item to the cart, entering billing and shipping details, receiving the confirmation, and so on. When we complete atomic tests then we reached to bronze conformance level

 

holistic tests

 

holistic tests are nothing but testing with real end users who is people with disabilities. Based on the end user feedback, site may reach to silver or gold. we many times see that site claims to be compliant but not usable to people with disabilities, and this is actual problem today. To address this problem, holistic tests should help. There is not much information provided on holistic tests today in the official W3C document, but it is likely to be updated.

 

 

 

Scoring and rating

WCAG 2.x series is kind of more of pass/fail against each success criterion whereas WCAG 3.0 is kind of more of scoring for each outcome. The problem with pass/fail approach of WCAG 2.x is that we fail entire site/view even if one instance of particular checkpoint is not passed, and it is hard to measure like this if the view or site is really compliant or not. WCAG 3.0 is aiming to solve this problem with the new approach called scoring and rating. Let us understand how this scoring works. Outcomes have the methods and methods have the tests to carry out based on the technology. outcomes will be assigned the scoring range from 0(very poor) to 4(excellent). The scoring of outcomes is also dependent on the number of critical errors that are found. If there are critical errors, then scoring goes very low. another important point is that overall scoring must be 3.5 in order to comply the site/view at the bronze level. the overall scoring is depending on the 2 factors. One factor is that average of aggregate outcome must be at least 3.5 rating. Another factor is that each functional category must be at least 3.5 scoring. Please note that the scoring that is being discussed here is for atomic tests whereas the scoring of holistic tests at silver and gold level is not having much information in the W3C document. The below details clearly provide how the scoring is assigned

• Very Poor (0): Any critical errors or less than 50% of related tests pass
• Poor (1): No critical errors, approx. 50% to 79% of related tests pass
• Fair (2): No critical errors, approx. 80% to 89% of related tests pass
• Good (3): No critical errors, approx. 90% to 98% of related tests pass
• Excellent (4): No critical errors, approx. 99% to 100% of related tests pass

 

Based on the above rating information, site/view is said to be accessible even 99% of the things are accessible but need not to be 100%, and this seems to be good approach I personally feel.

 

 

 

How the conformance model is structured

 

WCAG 3.0 has 3 levels of conformance, and they are bronze, silver, and gold. WCAG 3.0 does not have any more level A, level Aa, level AAA.

 

Bronze

To comply with WCAG 3.0, site/app/any technology meet at least bronze level. The success of atomic tests reaches the site/app/any technology to the bronze level. In order to reach the bronze level, site/app/any technology must need the total score and score within the functional category to be at least 3.5 rating. in addition, there should not be any critical errors in both views and process at the bronze level. Another important aspect is that if the content is compliant to the bronze level, then it does not mean that it met all the requirements, but it is meant that it does not have any critical errors and it is minimally compliant.

 

 

 

Silver and gold

Silver and gold are the next level of conformance. To comply with silver and gold, content must meet minimum bronze level as well as must be usable for the people with disabilities. Holistic tests are needed to perform usability testing with the real users. There is not much information provided on the silver, gold, holistic testing approach in the official W3C document and it is likely to be updated.

 

 

 

 

 

 

 

Important data points to remember

1. WCAG 3.0 is not backward compatible with WCAG 2.X (2.0, 2.1, or 2.2).
2. WCAG 3.0 does not supersede WCAG 2.2 and previous versions. It is an alternative set of guidelines.
3. WCAG 3.0 will likely not be final until sometime in 2023. More details concerning the scoring mechanism, which is not yet finished, and more outcomes, are an essential part of upcoming “heartbeat” updates, which will occur periodically until WCAG 3.0 becomes a final W3C recommendation.
4. There are no more A, AA, AAA levels in WCAG 3.0, so don’t go looking for them. The scoring mechanism replaces them.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

References

 

W3C WCAG 3.0

 

jspellman blog

 

 

Success Criterion 1.4.11 Non-text Contrast (Level AA):

The visual presentation of the following has a contrast ratio of at least 3:1 against adjacent colour(s):

• User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author.
• Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

 

 

 

Description

 

problems/challenges

As you know, there is a contrast related checkpoint in the WCAG 2.0 which is 1.4.3 contrast(minimum). This checkpoint talks the contrast of the text and images of text alone. However, WCAG 2.0 1.4.3 contrast does not talk the contrast of the icons, meaningful graphical objects, or any other non-text related things. When non-text elements (such as icons, graphical objects, and so on.)  do not have sufficient contrast then people who are low vision users would be having difficulty in perceiving those elements.

WCAG 2.0 does not also talk contrast of the controls/elements that require visual information and if those elements/controls have insufficient contrast then it would be difficult in identifying the same for the moderately low vision users. For moderately low vision users, even different states of those user interface components are difficult to identify if the contrast is insufficient. There would be many states for the user interface components. The examples of such states could be selected, focussed, hovered, checked, current, pressed, expanded/collapsed, active, enabled, and so on. if those states do not have enough contrast, then it is going to be difficult for moderately low vision users in perceiving the same. Overall, there are certain challenges/problems in identifying the user interface components (that require visual information), icons, meaningful graphical objects, various states if enough contrast is not maintained with its adjacent colours.

 

 

Solution

WCAG 2.1 introduces new check point called 1.4.11 non-text contrast to address mentioned problem. This success criterion emphasizes on the few things. They are.

1. The informative icons (such as status, print, and so on.) that do not have any associated text must meet 3:1 contrast ratio with its adjacent background
2. The user interface component that is identifiable with the visual information alone (ex: text input with dark border around white editable area) must meet 3:1 contrast ratio with its adjacent colour
3. The state of user interface components (such as selected, active, expand/collapse, and so on.) must meet 3:1 contrast ratio with its adjacent colour
4. Meaningful graphical objects (such as graphs, charts, and so on.) must meet 3:1 contrast ratio with its adjacent colour

 

If author follows the above 4 mentioned points, then moderately low vision users would not have any difficulty in accessing/perceiving those non-text things.

Complementary info on 2.5.4: motion actuation

This checkpoint does not talk about the contrast of inactive user interface components.

 

Exceptions

 

There is no need of meeting the contrast if the graphic is essential (essential in the sense it cannot be represented other than graphic). The logos, flags, screenshots, diagrams, photos, and any other such things. are the exceptions for this checkpoint

 

 

 

References

understanding 1.4.11: Non-text Contrast

 

 

 

Success Criterion 2.5.4 Motion Actuation (Level A): Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

• Supported Interface

  The motion is used to operate functionality through an accessibility supported interface;

• Essential

  The motion is essential for the function and doing so would invalidate the activity.

 

 

 

 

 

 

Description

 

We sometimes see that actions/functionalities in the digital space would take place as soon as there are certain movements either with the device or user. the functionalities/actions related to  user motion or device motion are mostly seen in the mobile native apps and rarely seen in the mobile web apps. the simple examples could be shaking the device to undo the action, tilting the device to advance to the next or a previous page, gesturing towards camera to cause certain action.

 

problems/challenges

 

Although movements such as shaking, tilting, gesturing towards, seem to be easy to perform for the person who does not have disability, however, the same movements are difficult or impossible to perform for the certain group of users. Let us understand this with some scenarios how difficult it is when the actions are associated with either user or device motions

1. If the device is mounted to the wheelchair, it is not possible for the wheelchair user to shake or tilt the device to perform action
2. If the user is having motor disability, neither it is possible to move the device to perform action nor it is possible to gesturing towards camera to perform action
3. If the user is having tremors, user can accidently perform unintended actions that are related to device motion (such as shaking/tilting). As a result, it is not easy for those users to use the device smoothly.
4. Even users who do not have disabilities, but their hands are occupied, it is not possible for those users to move the device to perform action

 

In a nutshell, associating actions/functionalities with the certain movements pose problems/challenges to some group of users.

 

 

 

Solution

WCAG 2.1 introduces the new checkpoint called “2.5.4: motion actuation” to address the mentioned problems. This success Criterion states that Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation. To put this simpler if there is any user or device motion to perform action;

1. Authors must provide the user interface control as an alternative to perform the same action. The below are the examples
   • after inputting text at the text field, user must shake the device to undo the action. the cancel button is provided beside the text field to do the same action
   • user must shake the device to roll the dice in the app. Control is provided to roll the dice
   • user can tilt the device to advance to next and previous pages. the controls are provided to do the same action
2. Authors must provide the settings to disable or turn off those user or device motions to prevent the accidental activations.

 

When the authors follow the above mentioned 2 points, the design is going to be inclusive and all the users including people with disabilities can perform the actions (related to movements) with not only the device or user movements but also with the simple tab or touch.

 

 

 

 

 

 

 

 

Complementary info on 2.5.4: motion actuation

This checkpoint is mostly applicable for the mobile devices and motion actuation things are built in the few native apps, but We rarely find motion actuation instances in the mobile websites.

 

 

 

Exceptions

 

There are exceptions to this success criterion.

1. If the user motion or device motion is part of the accessibility feature, then it is an exception case. For example; eye gazing technology uses eye movements to access the computer, and this is an exception because it is assistive technology for the certain group of people with disabilities.
2. If the device motion or user motion is an essential activity and disabling it or turning it off invalidates the entire thing then it is an exception. For example; A pedometer that relies on device motion to count steps is an example of such an essential activity.

 

References

understanding 2.5.4: Motion Actuation

 

 

 

 

 

 

 

Success Criterion 2.5.2 Pointer Cancellation (Level A): For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event

  The down-event of the pointer is not used to execute any part of the function;

• Abort or Undo
  Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
• Up Reversal
  The up-event reverses any outcome of the preceding down-event;
• Essential
  Completing the function on the down-event is essential.
  Functions that emulate a keyboard or numeric keypad key press are considered essential.

 

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

 

 

Description

User interface controls should use up event for the activation. Up event is nothing pointer release but not pointer press down. All the users including people with disabilities use pointers to interact with the controls. The pointers could be mouse, touch, stylus and so on..

Problems/challenges

 

While interacting with the controls, at times users may accidentally click or touch a button or target location which triggers an unwanted action. This may happen more frequently to people with tremors, mobility impairments, or cognitive disabilities. Let us look into this with few examples.

1. Person with hand tremors touches on the end call button in the web conferencing platform instead of mute button and as a result, the call gets disconnected
2. Person with motor impaired touches on the submit button in the assignment form instead of cancel button and as a result, the assignment gets submitted
3. Person with cognitive disability clicks on the close dialog element of the partially filled form and as a result, the form gets closed without saving the data

 

Therefore, it is essential that all users have a way to prevent or undo these unintended actions. If the system is not allowing to undo or prevent unintended actions that are caused by user mistake then it is going to create huge problem to people with disabilities.

Solution

 

WCAG 2.1 introduces new check point called 2.5.2 pointer cancellation”” to address mentioned problem. This success criterion emphasizes on the four things. They are;

1. No down-event: controls are not supposed to activate the functionality with the down event. Ex: when user touches on the end call button by mistake instead of mute button then he/she can slide off the finger to cancel the action. On the similar lines, when the user touches the submit button instead of cancel button and he/she can slide off the finger from the target location and release the finger to cancel the action
2. abort or undo: there should be mechanism provided to abort or undo the action. Ex: when user clicks on the close dialog element of the partially filled form then system should be able to throw confirmation message like do you want to save the data to undo the action.
3. up reversal: up-event should reverse the functionality of down-event. Ex: when user press-and-hold the element with the pointer then it opens the popup. However, the popup should be dismissed as soon as user releases the pointer/up-event activation
4. essential: it is essential to use down-events to activate few functionalities and this checkpoint is an exception for such activities. Ex: when the user is entering the data with on screen keyboard then data is going to be entered with the key press down but not key up event. On the similar lines, when user is playing on-screen piano keyboard then the keys get activated with down-event only.

 

 

If author follows the above 4 mentioned points then issues with the pointer are going to be taken care.

 

 

Complementary info on the 2.5.2: Pointer Cancellation

Pointer cancellation checkpoint does not apply to actions that are required to operate the user agent or assistive technology and this checkpoint applies to author supplied web content only. Pointer cancellation checkpoint should be taken care even for the complex actions such as drag and drop. Even though there are series of the actions present(pressing down the pointer, drag the pointer, release the pointer)  in the drag and drop, users should be able to abort the action before completion or undo the action after the completion.

 

 

 

References

 

understanding 2.5.2: Pointer Cancellation

 

 

Success Criterion 1.3.5 Identify Input Purpose (Level AA): The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section ; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

 

 

 

 

Description

As you are aware of, most of the websites use the forms to collect the data and we hardly find the website that does not have form. Some websites use the form for account signup and some other uses for email subscription and much more. to put this simpler, there are many types of forms exist and forms are everywhere on the web. Having clear labels or instructions for each form field on the form helps most of the users in filling the form but it may still pose some challenges for certain disabilities to fill the form.

Problems/challenges

In spite of having clear labels or instructions for the each form field, to identify the purpose of the each form field and fill the form, it may still create challenges for the people with cognitive disabilities, people with language and memory issues, people with low dexterity, and so on.. Let us understand how these users are impacted by forms

• Certain group of cognitive disability users find it very difficult to understand the purpose of the form fields with the help of text labels and these results difficult in filling the form
• Low dexterity users find it difficulty in filling the form by typing the same data across the different websites
• People who are having language and memory issues find it difficult to fill the form by remembering data of few form fields such as address, phone number and so on.
• Dyslexia users find it difficult to fill the form by getting the spellings and numbers right

 

 

Solution

WCAG 2.1 introduces the new checkpoint called “1.3.5: identify input purpose” to address the mentioned problems with forms. This success Criterion states that the purpose of each input field collecting information about the user can be programmatically determined. To satisfy this success criterion, authors must use HTML autocomplete attribute in order to programmatically determine the input fields. In addition, the token value of autocomplete must be matched as per the section 7 of WCAG 2.1. here are some example token values of autocomplete attribute.

• For the name input field, autocomplete=”name”
• for the first name, autocomplete=”given-name”
• for the last name, autocomplete=”family-name”
• for the email , autocomplete=”email”

 

 

and like this, there are 53 such token values for autocomplete. Author needs to look at list thoroughly and define the appropriate token value based on the purpose of the input field. You might be wondering how this autocomplete attribute helps for those disabilities that stated in the problem section of this blog post. Let us understand how autocomplete helps for those users. When autocomplete is defined with appropriate token value based on the input purpose

• cognitive disability users who cannot understand the purpose of the input field with the help of text labels will be able to understand the purpose of the input fields with the help of icons/symbols. For example, assistive technology used by cognitive disabilities insert the cake icon beside the date of birth input field when autocomplete=bday”is defined for the date of birth input field
• it reduces the burden for low dexterity users, language disability users, dyslexia users in typing same data(ex: email), remembering the information(ex: address), and correcting the spellings across the multiple websites as it is going to auto fil the data

 

 

Complementary info on the 1.3.5: identify the input purpose

This checkpoint is applicable only for the input fields that collects the user/personal data(ex: your email) but this checkpoint is not applicable for the input fields that collects the someone else data(ex: recipient email id). Apart from that, If the purpose of the input field is not present in the section 7 of WCAG 2.1 then this checkpoint is not applicable. Moreover, type ahead(edit combobox) is not covered as part of this checkpoint. In addition, if the technology is not supported to define autocomplete attribute then this checkpoint is not applicable.

Theoretically, assistive technology of cognitive disabilities inserts the symbols/icons based on the autocomplete value that author defined, but such assistive technology is not present as of now. It is assumed that future assistive technologies will have the those capabilities.

 

 

 

References

 

Understanding 1.3.5: identify input purpose

 

 

Success Criterion 2.1.4 Character Key Shortcuts (Level A): If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off

  A mechanism is available to turn the shortcut off;

• Remap

  A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);

• Active only on focus

  The keyboard shortcut for a user interface component is only active when that component has focus.

 

 

 

 

 

Description

 

Some applications may have character key shortcut keys to trigger actions and this character key shortcuts help keyboard users in using the application efficiently and effectively. Before we understand how the character key shortcuts are used by different users, it is important to know what is this character key shortcuts all about

Character key shortcuts are nothing, but actions get performed/triggered as soon as user presses characters on the keyboard, and this characters include letters(upper-case and lower-case), punctuations, numbers or symbols. Let me explain you this with an example. As you all know, there is popular web Gmail application to check our emails. Gmail has provided character key shortcuts for the users to perform certain actions quickly. When user presses character “Y” in the Gmail web, for the instance, email is going to be archived. Similarly, when user presses “M”, for the instance, mails are going to be muted.

 

Problems/challenges

 

although this character key shortcuts are very helpful for the keyboard users in accessing the things quickly, it creates problems for the speech input users and low dexterity users. Let us understand how this character key shortcuts are going to create problems for those users.

As you may be aware of, speech input users use speech recognition software such as dragon to access the computers/web. While dictating the text at the text field by speech user when character key shortcuts are present then it is going to pick the character key shortcuts instead of the text is being typed at the text field. This behavior creates problem to speech input users and as a result, speech input users cannot use the application properly. On other hand, there are some keyboard users(such as users with low dexterity, users with tremors, and so on.) who are prone to hit the keys accidently. When they do so, character key shortcuts get enabled unexpectedly. This behavior ends up with frustrating experience for such users. In a nutshell, character key shortcuts create challenges/problems for the speech input users and some keyboard users(such as users with low dexterity, users with tremors, and so on.)

 

 

Solution

WCAG 2.1 introduces character key shortcuts checkpoint to address the challenges with character key shortcuts that people with disabilities face. When author follows the guidance that is provided in this checkpoint then the challenges with character key shortcuts are going to be resolved. Let us look into what guidance this checkpoint is providing

 

1. Turnoff: users should be able to turn off/disable the character key shortcuts, so that It helps both speech input users and low dexterity users to access the applications without any difficulties
2. Remap: users should be able to remap the shortcuts with one or more modifier keys(such as alt, shift, control, and so on…), so that It helps both speech input users and low dexterity users to access the applications without any difficulties
3. Active only on focus: users should be able to use the character key shortcuts only when that UI component(such as listbox, dropdown, and so on…) is in focus, so that it does not create a problem for any user

 

When author follows any one of above 3 points then challenges with the character key shortcuts that I mentioned in the problem section of this blog post are going to be addressed. In a nutshell, both speech input users and low dexterity users would not face any challenges when one of above 3 points is met.

 

 

 

Exceptions

This checkpoint is not applicable for the UI components such as listboxes and drop-downs. the reason is that, even though character key shortcuts are present for those UI components, those character key shortcuts work only when the UI components are in the focus. Therefore, this checkpoint does not affect such UI components.

 

Complimentary info on 2.1.4: character key shortcuts

When users have the provision to remap the character key shortcuts then it is going to help cognitive disability users too. Remapping the character key shortcuts with user’s familiar keyboard short cuts helps the users to use the same keyboard shortcut keys across various applications and thereby, it reduces the cognitive load.

 

 

References

 

• Understanding 2.1.4: Character Key Shortcuts
• Video: Single character key shortcuts affecting speech input – example 1
• Video: Single character key shortcuts affecting speech input – example 2

 

 

Success Criterion 1.4.10 Reflow (Level AA): Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

 

 

Description

As you may be aware of, certain group of low vision users use browser zoom functionality to see the web content. However, this sometimes might be difficult to view the content by scrolling in both horizontal and vertical directions. To put it simpler, it takes lot of time and effort to read the web content by scrolling into both the directions. This is kind of problem.

WCAG 2.1 introduced the new checkpoint called “1.4.10: reflow” to address such problems for the low vision users. This success criterion requires Content to be presented without loss of information or functionality, and without requiring scrolling in two dimensions when the content is zoomed up to 400%. When authors follow this success criterion then entire web content reflows in one single column  without horizontal scrolling at 400% zoom. This enables low vision users to read the web content smoothly without horizontal scrolling.

Another important point to remember is that reflow should happen only at 400% zoom of screen resolution 1280px by 1024px but reflow need not to happen at 400% zoom of any screen resolution. This means that 400% zoom at screen resolution of 1280px(width) by 1024px(height) is nothing but 320px(width) by 256px(height). To put the things simpler, authors need to make sure that content should reflow either at 320px by 256px screen resolution or at 400
% zoom of 1280px by 1024px screen resolution. Basically, if your site is responsive then this checkpoint is almost going to be satisfied

 

Exceptions

This checkpoint is not applicable for the content that requires 2-dimensional scrolling. The reason is that such content will not deserve the meaning if it reflows in one direction. Examples of such content are data tables, videos, graphs, and so on.

 

 

Complimentary info on 1.4.10: reflow

The success criterion applies to both horizontally and vertically written languages. When 400% zoom is done on the horizontally written language content that scrolls vertically(ex: English)then it should not have horizontal scrolling. Similarly, when 400% zoom is done on the vertically written language content that scrolls horizontally then it should not have vertical scrolling. For the content that is horizontally written languages, the content should reflow vertically at 320px(width). For the content that is vertically written languages, the content should reflow horizontally at 256px(height).

It is often misunderstood that 1.4.4-resize text and 1.4.10-reflow are kind of similar, but both are different concepts. 1.4.4-resize text talks about all the content and functionality should be available at 200% zoom whereas 1.4.10-reflow talks about the all the content and functionality should be available at 400% without horizontal scrolling.

 

 

 

References

• Understanding Success Criterion 1.4.10: reflow

 

 

 

 

 

Success Criterion 1.4.13 Content on Hover or Focus (Level AA): Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

Dismissible

A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

Hoverable

If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

Persistent

The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

 

Description

While browsing the web, we quiet commonly see the tooltips. These tooltips typically appear when we hover or focus on the elements. Authors use these tooltips to provide more information about the trigger/target. Tooltip content could be submenus, non-modal, help text, so on… Users without disabilities neither have any concern accessing the tooltip content nor have disruptions with the tooltip content. However, users with disabilities might have disruptions with the tooltip content as well as problems/challenges in accessing tooltip content itself. tooltips, in general, impose lot of challenges to people with disabilities and let us look into them in-detail.

Problems/challenges with the tooltips

 

1. You might know that certain group of low vision users use screen magnifier to view the web content. When these users magnify the web content, only less portion of the web content is visible in the view port. To access the complete web content, users of magnifier need to keep on pan the screen by using pointer and view the content in the restricted area. Imagine if entire portion of the restricted view port triggers additional content/tooltip then it is difficult or impossible for the users to pan the screen without retriggering additional content, and this is going to create a very big problem for such users.
2. You might know that certain group of low vision users use keyboard. While accessing the web, low vision users who use keyboard may encounter the unexpected tooltips when they focus on the certain elements. This unexpected behavior may create a problem for the low vision users in accessing the obscured content.
3. You might know that certain group of low vision users use large cursors. When those users use large cursor then large cursor may overlap the additional content/tooltip that is displayed on hovering the trigger/target. To view the additional content/tooltip content in such scenarios, users of low vision might have to move the pointer from trigger/target to the additional content/tooltip content. While doing so, tooltip content sometimes may get disappeared altogether, and this makes difficult or impossible for the low vision users to access the tooltip In addition, magnifier users might also need to move their mouse pointer to tooltip content to view/access the tooltip content properly. It is impossible or difficult for such users to view/access the tooltip content if the tooltip content gets disappeared as soon as pointer off from the trigger/target.
4. You might know that certain group of cognitive disabilities take longer time to perceive the content. While they are perceiving the tooltip content, tooltips sometimes get disappeared automatically. When tooltips disappear automatically after a while then it is going to be difficult for such users to perceive the tooltip content.

 

Solution

WCAG 2.1 introduces content on hover or focus checkpoint to address the tooltip challenges that people with disabilities face. When author follows the guidance that is provided in this checkpoint then most of the tooltip challenges are going to be resolved. Let us look into what guidance this checkpoint is providing

1. Dismissible: tooltip content should be dismissed when user presses escape key in the keyboard unless tooltip content does not obscure any content or tooltip content displays on the white/decorative background. This condition helps to resolve the problem 1 and 2 that are mentioned in the problem section of this blog post.
2. Hoverable: user should be able to hover the tooltip content when pointer is moved from trigger/target to the tooltip content. Basically, the tooltip content should not be disappeared as soon as pointer of from the target. This condition helps to resolve the problem 3 that is mentioned in the problem section of this blog post.
3. Persistent: tooltip content should remain on the screen unless user dismisses it or user navigates away from both trigger and tooltip content or the instance itself is invalid. Basically, tooltip content should not be disappeared after a while. This condition helps to resolve the problem 4 that is mentioned in the problem section of this blog post.

 

 

 

When author follows these 3 conditions then most of the tooltip challenges that I mentioned in the problem section of this blog post are going to be addressed. In a nutshell, people with low vision and people with cognitive disabilities would not face most of the tooltip challenges when the conditions of this checkpoint are met.

 

 

 

 

 

 

exceptions

This checkpoint is applicable only for the author supplied tooltips but not user agent based tooltips. To give an example, tooltips that are displayed with the HTML title attribute are an exception to this checkpoint.

 

 

References

• Understanding Success Criterion 1.4.13: Content on Hover or Focus

 

 

 

 

Success Criterion 2.5.3 Label in Name (Level A): For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

A best practice is to have the text of the label at the start of the name

 

Description

 

There are certain group of people with disabilities, especially who are having learning and physical challenges, use speech recognition software like dragon naturally speaking to access the computers. Let us understand what speech recognition software is all about. Speech recognition software converts speech to text as opposed to the screen readers. Those users of speech recognition software access the computers with the speech input and there are voice commands to perform the regular activities on the computer like opening MS word document, , opening files/folder, sending the email, browsing the web and so on.. now that we understand that how those users of speech recognition software access the computers. On the similar lines, when user is trying to activate the send button by using voice commands after composing the email, for the instance, send button does not get activated in spite of the multiple attempts. The reason could be that, even though there is a visible text as send for the user interface control but the control may not have same text as an accessible name in the accessibility tree rather control has the submit as an accessible name in the accessible tree. As visible name of the control is send and accessible name of the control is submit, speech recognition software never understand and never activate this control  when user is trying to activate send button with the speech input. This creates problem and intern it impacts the ability to use the control itself for those users of speech recognition software.

In order to address this problem, WCAG 2.1 introduce this new SC. The intent of this Success Criterion (SC) is to help ensure that people with disabilities who rely on visual labels can also use those labels programmatically. In other words, the accessible name of the control must contain the text that is visible on the control but It does not mean that accessible name of the control need not to be identical with the visible label of the control. In addition, when the accessible name is different from visible label of the control then it is high chance that speech input users may accidently activate the hidden commands. As a result, speech input users get confused and disoriented with the unexpected actions. Text to speech(screen reader) users get best experience when accessible name of the control is matched with the visible name of the control.

Pass scenarios

• Accessible name of the control matches visible label of the control
• the words of the visible label in the accessible name are not scattered and are in the same order as they are in the visible label

 

References

• WCAG 2.1: Success Criterion 2.5.3 Label in Name
• Understanding Success Criterion 2.5.3: Label in Name