Back in August 2022, we had published a blog on WCAG 2.2 AQuick start Guide to find out what to expect from the new version of the guidelines. Since then two Candidate Recommendations of the guidelines have been released. The first one in September 2022 and the second one in January 2023. In this post, we will see what has changed from new success criteria’s, and removal of a success criteria to minor changes in the terms used in different success criteria’s.

The changes have been included at the start of each section of the below post for easy identification. In all there are 9 new success criteria’s being added in WCAG 2.2 as per the latest Candidate Recommendation. 1 success criteria, 4.1.1 Parsing is obsolete and has been removed from the guidelines. In addition, the conformance level for 2.4.7 Focus visible success criteria has changed from Level AA to Level A in WCAG 2.2. Out of these 9 success criteria’s: 

• 2 are at Level A 
• 5 are at Level AA 
• 2 are at Level AAA 

Level A 

4.1.1 Parsing

The Parsing success criteria is obsolete and has been removed from WCAG 2.2 guidelines. This criteria is no longer useful because the accessibility errors that fail under this criteria are already covered by other success criteria’s. Additionally, modern browsers and assistive technologies can handle parsing errors and thus they are no longer creating accessibility errors for people with disabilities. WCAG 2.2 is backward compatible, i.e. it covers success criteria included in both WCAG 2.0 and 2.1. Even though 4.1.1 Parsing is removed from WCAG 2.2, it has not been removed from WCAG 2.0 and 2.1 as of now. In the future, this can happen for sure but for now in order to conform to WCAG 2.0 and 2.1 one needs to yet test for 4.1.1 Parsing at Level A. 

3.2.6 Consistent Help

The first “Note” of the success criteria has changed. As per the note, the help mechanism can be either provided on the page directly or a direct link can be provided to the page that contains the information.

The purpose of this success criteria is to ensure that users can find help consistently at the same location across different pages of the website or application. Finding help at a consistent location is beneficial for users with cognitive disabilities who would like to access help when they are not able to complete any task, such as filling up a form.

Help on a website can be in the form of: 

• Contact information, email address, phone number, office timings
• Contact form, messaging application, chat application, social media channel
• Support page, FAQ page
• Chatbot 

3.3.9 Redundant Entry

The purpose of this success criteria is to provide users with an option to either select previously filled details or auto-populate the details. This will avoid the need to enter the information again by users in a multi-step form and is found very helpful by users with cognitive impairments. This success criteria can be met by providing users to select previously filled information in the form of a drop-down and they can simply select the details. Alternatively, users can simply tick a checkbox, such as Nominee address is same as Applicant’s address or copy and paste the textual information in the respective input fields.

Exceptions include: 

• Auto-populating the information will affect the security of the form.
• It is essential to enter the information again as it is part of the activity, i.e. in the case of a memory game. 
• Previously entered information is no longer valid.

Level AA 

2.4.11 Focus Appearance

The purpose of this success criteria is to ensure that the focus indicator for user interface controls is clearly visible and discernable. This will help users with mobility impairments and those with low vision who use a keyboard to easily locate their focus on the page.

The success criteria require that a visible focus indicator meets either one or both of the below-mentioned requirements: 

The entire focus indicator meets all the below requirements: 

• Focus indicator encloses the user interface component or sub-component that is focused, i.e. solidly surrounds the control. 
• Focus indicator should have a minimum contrast of 3:1 between its pixels and its focused and unfocused states. 
• Focus indicator pixels should have a contrast of 3:1 with the adjacent non-focused indicator colors.
• An area of the focus indicator meets all the below requirements: 
• Area of the focus indicator is at least 1 CSS pixel thick of the unfocused component or sub-component, or is at least 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component. 
• Area of the focus indicator should have a minimum contrast of 3:1 between its pixels and its focused and unfocused states. 

The area of the focus indicator pixels should have a contrast of 3:1 with the adjacent non-focused indicator colors or is not less than 2 CSS pixels. 

Exceptions include: 

• Focus indicator is determined by the user agent, such as web browsers.
• Focus indicator and its background is the default, i.e. generated by the browser and is not modified by the web page author. 

2.4.12 Focus Not Obscured (Minimum) 

The purpose of this success criteria is to make sure that when any user interface component receives focus, the component is not entirely hidden by any content created by the author. In order to meet this success criteria, some part of the component should be visible when it receives focus. For example, a non-modal dialog, sticky header/footer etc. can hide a focused component as well as its focus indicator. At any point, the user should be able to identify which component has focus currently on the page. This requirement is beneficial for people with low vision and those with mobility impairments.

2.5.7 Dragging Movements

The purpose of this success criteria is to help users carry out dragging functionalities through alternative means. People with dexterity impairments might find it difficult to carry out drag and drop activities or change values of a slider. Including an alternative method for functionalities based on dragging will help users accomplish their task easily.

A web page can provide users with drop-downs to select minimum and maximum price along with price range sliders in order to meet the success criteria. This success criteria does not apply to dragging movements that are part of user agents including assistive technologies and browsers. 

2.5.8 Target Size (Minimum)

In this success criteria, there are changes related to “Exceptions” for spacing and inline as well as “Note” for inline targets and line-height which are covered below. 

The purpose of this success criteria is to help users easily activate user interface controls and avoid unintentional activation of controls. When target sizes for controls are small users with mobility impairments who find to precisely control mouse movements will find it difficult to activate controls. Similarly, users browsing the web via mobile devices will also benefit by defining minimum target size of controls.

The minimum target size for pointer inputs is 24 by 24 CSS pixels. This requirement has the following exceptions:

• Spacing: The target does not overlap with any other target and has a target offset of at least 24 CSS pixels with every adjacent target. 
• Inline: The target is within a sentence or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text. 
• Essential: It is essential to present a target with smaller size than the minimum recommended 24 CSS pixels. 
• User Agent Control: Target size is determined by the user agent and not defined by the page author. 
• Equivalent: An equivalent control exists on the page that meets the minimum target size requirements. 

In the case of inline targets, the line-heights should be interpreted as perpendicular to the flow of text. So for language that is displayed top – to – bottom, the line-height would be horizontal.

3.3.8 Accessible Authentication 

Before the release of the first Candidate Recommendation, this success criteria was at 3.3.7. The first “Note” of the success criteria has changed. As per the “Note”, “Object recognition” and “Personal content” may be represented by images, video, or audio. 

The purpose of this success criteria is to provide users with an accessible, easy to use and secure means to login and perform tasks. Users with cognitive disabilities who might not be able to memorize usernames or passwords rely on copy and paste functions and password managers to enter their credentials. If a website uses scripts that block password managers or copy and paste functions, then it becomes difficult for users to login into their accounts and perform different tasks.

The success criteria requires that authentications are easy to use, accessible and secured. Authentication should not require cognitive function and if they are based on cognitive function than an alternate method is made available.

Cognitive function that requires users to recognize objects or provide content to the website is considered as an exception to the success criteria.

Level AAA 

2.4.13 Focus Not Obscured(Enhanced)

Before the release of the first Candidate Recommendation of WCAG 2.2 this success criteria was named as 2.4.12 Focus Appearance (Enhanced).

The purpose of this success criteria is to make sure that when any user interface component receives focus, the component is fully visible and is not hidden by any content created by the author. This success criteria is similar to 2.4.12 Focus Not Obscured (Minimum) and the only difference is that it requires that the focus be fully visible whereas as per 2.4.12, it is acceptable even if only some part of the focus is visible. 

3.3.9 Accessible Authentication (Enhanced)

As per the first Candidate Recommendation of WCAG 2.2 this success criteria was named as Accessible Authentication (No Exception). The criteria has now been renamed to Accessible Authentication (Enhanced). 

The purpose of this success criteria is to provide users with an accessible, easy to use and secure means to login and perform tasks. Users with cognitive disabilities who might not be able to memorize usernames or passwords rely on copy and paste functions and password managers to enter their credentials. If a website uses scripts that block password managers or copy and paste functions, then it becomes difficult for users to login into their accounts and perform different tasks.

The success criteria requires that authentications are easy to use, accessible and secured. Authentication should not require cognitive function and if they are based on cognitive function than an alternate method is made available. This success criteria is similar to 3.3.8 Accessible Authentication but does not include exceptions related to objects and user-provided content.

Would be great to see what the finally published WCAG 2.2 Guidelines looks like. The number of success criteria for meeting conformance will increase by 9 and take the total to 86 at Level AAA and 56 at Level AA if none of the above is removed! 

We would be happy to assist you with any questions or information you need related to WCAG 2.2 or accessibility. Get in touch with our accessibility consultant at sales@barrierbreak.com.

The post WCAG 2.2 – What to expect as per January 2023 Update! appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

The post WCAG 2.2 – A Quick Start Guide appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

VPAT 2.0 was expanded to include the leading ICT accessibility standards, the Revised Section 508 (US), EN 301 549 (EU) and W3C WAI’s Web Content Accessibility Guidelines (WCAG) 2.0. Information Technology Industry Council (ITIC) develops the VPAT and ensures that it is updated with the latest developments happening in different ICT accessibility standards and guidelines.

VPAT comprises of different Editions, WCAG, Section 508, EN 301 549 and International (Int) that include different accessibility standards and guidelines. The INT Edition of VPAT includes all the 3 leading ICT accessibility standards.

VPAT 2.4 was revised in February 2020 and was made available for download on March 7, 2020. Discuss your VPAT Strategy with an Accessibility Expert today. 

VPAT 2.4 Updates

Some of the key changes in VPAT 2.4 are:

• Template date: template date is now removed from the document as it created confusion with the Report date. The date will be there in the filename and only version information will be present in the document.
• Edition specific instruction: Instructions are changed based on the Edition, for e.g. in the WCAG Edition, only instruction related to WCAG is available.
• Table heading: A table missing heading in the previous version is now been added.
• EN 301 549 version: Links and tables of the EU and INT Editions are updated to reflect the new version of EN 301 459.

All in all, major update in VPAT 2.4 is associated with the EN 301 549 which reflects the new version of the standard and the other updates are relatively minor ones. So if you are focusing on the European Markets, time to update your VPATs.

We would love to hear from you! Share your inputs with us using the comments box below!

As a VPAT vendor, we provide VPAT audit support to our customers by conducting Section 508 testing and assisting them to create a VPAT and ACR for their product wherein we provide a third-party view of the product. If you are looking for an external accessibility consulting agency to author or update the VPAT for your product or service, write to us at sales@barrierbreak.com!

The post What’s new in VPAT 2.4? appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Having worked with multiple screen readers over the years has always excited me as it gives me one more option to explore. Especially screen readers that are bundled with the operating system as we do not have to install additional software in order to use our computer.

In the past, have already tried my hands with VoiceOver on Mac, ChromeVox on Chrome Book, TalkBack on Android and VoiceOver on an iPhone, so decided to try my hands on Narrator for Windows.

Let’s start with the basics of Narrator.

Narrator Basics

Press Windows Logo key + Control + Enter to turn Narrator on and off!

As soon as we launch Narrator, the QuickStart guide begins. The purpose of QuickStart is to help users learn basics of Narrator quickly. This is certainly a good-to-have feature when you are learning Narrator but later on it is something that users will get annoyed with. Microsoft has done the right thing by providing users with an option to prevent it from starting automatically each time Narrator is launched.

Simply select the checkbox “Don’t show this guide again” to prevent the QuickStart guide from starting automatically. One can turn it back on by selecting the “Learn Narrator basics with QuickStart” link available in Narrator Settings.

Just like any other screen reader, Narrator also has a key assigned to it which is referred to as Narrator key”. In fact, Narrator has two keys!

By default, both Caps lock and Insert keys function as Narrator keys. We can change the Narrator key any time from the Narrator Settings.

We can also lock the Narrator key so we do not have to press it for every keyboard shortcut!

Press Caps lock + Z to lock the Narrator key.

Tip: Press Ctrl key to silence Narrator temporarily.

The following table lists few of the basic Narrator commands for accessing information:

Tip: Press Caps lock + F2 to show the commands for interacting with the current item!

Having learnt the basic commands of Narrator, let’s now move ahead and find out how to browse the web using Narrator.

Narrator works pretty well with Microsoft’s Edge browser. So let’s get started!

Reading web pages

By default, Narrator switches to Scan mode while reading web pages using Edge. One can toggle Scan mode On/Off by pressing Caps lock + Spacebar in any application.

Narrator remembers the previously used Scan mode setting for an application and switches to it when you launch the application again. For edit boxes on the web, Scan mode is turned off automatically to help users type the text with ease.

Another important option that Narrator offers to its users is to work with different views. There are 11 views that users can chose from:

• Items
• Characters
• Words
• Lines
• Paragraphs
• Headings
• Links
• Form fields
• Tables
• Landmarks
• Suggestions

To cycle through different Narrator views press Caps lock + Up Arrow or Caps lock + Down Arrow

Switching between different views is especially helpful if you are using Narrator on a touch screen device. Yes that’s right, Narrator also supports touch screen gestures!

Along with reading text, Narrator identifies different web page elements, such as headings, lists, links, images, tables, form fields, etc. to help users access and interpret the information with ease. The following table lists down the commands to access different web page elements.

Apart from the above one can press number keys 1 to 9 on the Numeric row to jump to the headings at different levels on a web page. Yes, that’s correct 1 to 9 headings! Narrator gives options to jump to headings at level 7, 8 and 9 which are not commonly used on the web.

Just like any other screen reader, Narrator also provides users with several commands for accessing tabular information. So let’s find out the commands for accessing tables using Narrator.

Reading tables with Narrator

Tip: Press Caps lock + Ctrl + F to find text on a web page!

All in all Narrator has matured in to a useful screen reader option for users with visual impairments and is certainly a useful option not only to browse the web but also test web pages for accessibility!

The post Browsing the web using Narrator appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.

Being an equal opportunity employer ourselves and with approx. 65% of our staff comprising of persons with different types of impairments, procuring any solution for our offices has always been an interesting task. We have employees with wide range of impairments from hard-of-hearing to deaf, low vision to blind, as well as people with mobility and learning impairments. We take special care to ensure everything that we procure is inclusive to all and it was no different when we decided to procure a Biometric Time & Attendance System.

A Biometric Time & Attendance System is used across offices to login an employee’s in, out time and manage attendance as well as leaves etc.

We started with checking out different biometric systems and analyzed them for the modes of input to how the output is rendered. While different systems were analyzed, we involved our staff members with different types of impairments in the demonstration session to try out the system to make sure that we procured the system that will work for all the employees.

We finally decided to go with Biomax – Biometric Time & Attendance System to be installed at our different offices!

A lot of research and analysis was put in in procuring the system so we decided to share the learnings with the community at large through this post!

In this blog post, we’ll be discussing what all points need to be considered while procuring a Biometric Time & Attendance system that will be accessible for all the employees.

A Biometric Time & Attendance system usually comprises of:

• A scanner to take the finger impression
• A keypad to enter the password,
• Display screen showing the output and
• A punching card

Checklist before buying a biometric machine:

• Does the machine provide audio feedback for visual information displayed on the screen?
• Is there a dot on number “5” of the keypad to orient visually impaired people?
• Are textual and visual alerts used to supplement information displayed using color alone??

Audio feedback, dot on number “5”   as well as supplementing color with textual and visual alerts will aid your visually impaired employees use the machine independently!

• Does the machine provide textual messages for each sound alert?

This is required to assist employees with hearing impairments as they can follow the textual message and use the machine independently!

• Check if successful and unsuccessful attempts are indicated through different colors, i.e. green for a successful attempt and red for an unsuccessful attempt.

This will help employees with learning impairments quickly understand the feedback!

• Check if the machine offers more than one method of input, such as:
  • Placing the finger on the scanner
  • Type using the keypad or
  • Punch a card

This will aid employees with mobility impairments and even those with dry fingers!

Hope the above points will help many organizations in procuring accessible Biometric Time & Attendance Systems for their employees!

Do share how your organization has addressed accessibility in attendance systems.

The post What Equal Opportunity Employers should look for in a Biometric Time & Attendance System? appeared first on Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.