WCAG 2.2 - An Overview of the New Accessibility Guidelines.pptx
•
1 like•401 views
This document discusses the updates to the Web Content Accessibility Guidelines (WCAG) from version 2.1 to 2.2. WCAG 2.2 includes 4 new success criteria addressing issues like obscured focus, dragging movements, target size for pointers, and redundant data entry. It provides examples of these new criteria and discusses how they help people with disabilities. The document also mentions WCAG 3.0 and the importance of user research, giving an example of testing a site with someone who has Parkinson's disease.
More Related Content
What's hot
What's hot (20)
Similar to WCAG 2.2 - An Overview of the New Accessibility Guidelines.pptx
Similar to WCAG 2.2 - An Overview of the New Accessibility Guidelines.pptx (20)
More from AbilityNet
More from AbilityNet (20)
Recently uploaded
Recently uploaded (20)
WCAG 2.2 - An Overview of the New Accessibility Guidelines.pptx
- 1. WCAG 2.2 | December 2023 Outline • The Web Content Accessibility Guidelines (WCAG) • New WCAG 2.2 Success Criteria (A/AA) • Beyond WCAG 2.2 • Q&A 1
- 2. WCAG 2.2 | December 2023 WCAG in a nutshell WCAG is the Web Content Accessibility Guidelines and is a W3C Recommendation. It has three levels—A, AA, and AAA. We target AA which includes A and AA. It has four principles—Perceivable, Operable, Understandable and Robust. 2 4 Principles 13 Guidelines 86 Success Criteria
- 3. WCAG 2.2 | December 2023 History of WCAG – 1.0 to 2.2 WCAG 1.0 • May 1999 • 14 guidelines and 64 checkpoints WCAG 2.0 • June 2008 • 4 principles, 12 guidelines and 61 success criteria WCAG 2.1 • June 2018 • 4 principles, 13 guidelines and 78 success criteria WCAG 2.2 • October 2023 • 4 principles, 13 guidelines and 86 success criteria 3
- 4. WCAG 2.2 | December 2023 What’s new in WCAG 2.2? A AA AAA 3.2.6 – Consistent Help 2.4.11 – Focus Not Obscured (Minimum) 3.3.9 – Accessible Authentication (Enhanced) 3.3.7 – Redundant Entry 2.5.7 – Dragging Movements 2.4.12 – Focus Not Obscured (Enhanced) 2.5.8 – Target Size (Minimum) 2.4.13 Focus Appearance 3.3.8 – Accessible Authentication (Minimum) • 4.1.1 Parsing (A) removed and obsolete for WCAG 2.2. 4
- 5. WCAG 2.2 | December 2023 2.4.11 – Focus Not Obscured (Minimum) (AA) “When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” Helps people who use only a keyboard or assistive technologies via the keyboard interface to see where they are on the page at all times. Testing Demo 5
- 6. WCAG 2.2 | December 2023 2.5.7 – Dragging Movements (AA) “All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging.” Helps people who are unable to perform dragging movements, for example, because they use a head pointer and need a single pointer alternative. Testing Demo 6
- 7. WCAG 2.2 | December 2023 2.5.8 – Target Size (Minimum) (AA) “The size of the target for pointer inputs is at least 24 by 24 CSS pixels.” Helps people using mobile devices, those with tremors and other physical impairments, as well as people in shaky environments, such as on a train. 7
- 8. WCAG 2.2 | December 2023 3.2.6 – Consistent Help (A) “If a web page contains… help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order to other page content, unless a change is initiated by the user.” Helps everyone, but particularly people with cognitive and learning disabilities who are more likely to require help to complete a process. 8
- 9. WCAG 2.2 | December 2023 3.3.7 – Redundant Entry (A) “Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select.” Helps people with cognitive disabilities, particularly those with memory impairments. People with mobility impairments benefit from not having to enter as much data. 9
- 10. WCAG 2.2 | December 2023 3.3.7 – Redundant Entry (A): Some examples 10
- 11. WCAG 2.2 | December 2023 3.3.8 – Accessible Authentication (Minimum) (AA) A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following: • Alternative • Mechanism • Object Recognition • Personal Content Helps people with cognitive disabilities, particularly related to memory, reading, numbers or perception-processing to authenticate, log in, etc. 11
- 12. WCAG 2.2 | December 2023 Example Conformance for 3.3.8 12
- 13. WCAG 2.2 | December 2023 Would this pass 3.3.8? 13
- 14. WCAG 2.2 | December 2023 Example Failures for 3.3.8 • Requiring users to enter a password or code in a different format from the original, for example, by requesting a user enter the “1st, 2nd and 6th characters” of a password. • Password input that requires a user to select each character of a fixed-length password from individual dropdown fields. • Blocking users from being able to paste a password into the password field. • Blocking the use of integrated third-party password managers in input fields. • Having to manually transcribe a passcode from a secondary device such as a card reader. 14
- 15. WCAG 2.2 | December 2023 WCAG 3.0: W3C Accessibility Guidelines • Easier to understand, more user needs and addresses different types of web content, apps, tools and organisations. • Same goal as WCAG 2.2 – accessibility guidance for web contents and apps with specific accessibility requirements. • A different structure, conformance modal and encompass a broader scope beyond just web content. • Conformance levels will change to Bronze, Silver and Gold: • Bronze: Minimum conformance level for WCAG 3.0 • Silver: Incentivises organisations to go further to improve accessibility • Gold: For organisations that stand out as exemplary role models in accessibility 15
- 16. WCAG 2.2 | December 2023 User Research and Best Practice Testing with disabled users with a wide range or disabilities or impairments at every round of testing offers: • Deeper understanding of accessibility issues from a user’s perspective. • Practical insight into a site’s usability for people with disabilities. • Complements a WCAG audit to give you a more comprehensive accessibility evaluation. 16
- 17. WCAG 2.2 | December 2023 WCAG 2.2 and User Research: Meet Jordan • 55-year-old retired headmaster with Parkinsons • Tremors, difficulty with fine-motor control, attention impairment • Love of cooking, spending time with family • Desire for independence • Challenges using online platforms for shopping 17
- 18. WCAG 2.2 | December 2023 Questions? (3) 18
- 19. WCAG 2.2 | December 2023 Additional resources • W3C: What's New in WCAG 2.2 • W3C: Making Content Usable for People with Cognitive and Learning Disabilities – Provide a Login that Does Not Rely on Memory or Other Cognitive Skills • National Cyber Security Centre: Let them paste passwords • W3C: WCAG 3 Introduction • GOV.UK: Finding participants for user research – Recruiting disabled participants 19
- 20. WCAG 2.2 | December 2023 Thank you!
Editor's Notes
- Web Content Accessibility Guidelines (WCAG) A recommendation created by World Wide Web Consortium (W3C), that sits alongside HTML and CSS specifications as the standard for creating accessible content Internationally recognised and considered Gold Standard for web accessibility. Used as the de facto standard for some legislation, e.g. the UK Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations (2018), The European Accessibility Act (2025). Compliance levels – A, AA, AAA Usual target is AA, which includes all the A success criteria, this is considered an achievable level of compliance. AAA can be more subjective and difficult to achieve/less feasible. Four principles Perceivable – can it be perceived – do images and multimedia have appropriate alternatives, is there any information communicated through colour alone Operable – can it be operated – mouse, keyboard, switch, do users have enough time to complete tasks Understandable – can it be understood – are errors and instructions clear, does it work predictable, is the language of page set Robust – is it built to recognised standards These principles are split into 13 guidelines and then 86 success criteria – yes/no statements
- WCAG 1.0 – released May 1999. Contained 14 guidelines with 64 checkpoints. Had A, AA, AAA. Focused on HTML. Example criterion included providing text alternatives. Very focused on “physical” disabilities. WCAG 2.0 – Released Dec 2008. Big changes, 4 principles were introduced. Big changes in tech, reflected in guidelines. Applied to all digital content, not just HTML. Big increase in the number of disabilities/impairments which it covered. WCAG 2.1 – June 2018. Built upon 2.0. Still has 4 principles, 13 guidelines. If you comply with 2.1, you’ll comply with 2.0. More advancements in tech. Low vision, cognitive and mobile users. WCAG 2.2 – October 2023. Again, built upon 2.1. Backwards compatible, except for 4.1.1 Parsing, which is made obsolete. Improvements for people with cognitive impairments, low vision and mobility disabilities.
- Parsing removed as advances in standards and technology, including HTML, browsers and assistive technologies, mean that any issues that would fail 4.1.1 would fail other criteria, such as 1.3.1 Info and Relationships (A) or 4.1.2 Name, Role, Value (A). Four new SC focused on cognitive and learning disabilities/neurodivergence. Three new SC focused on low vision Two SC to enhance accessibility for those with mobility disabilities Talk about A/AA today Some we’ll look at how you can test them, others we’ll do demos of and some we’ll look at some examples and discuss if they’d pass/fail.
- When something receives focus, it is at least partially visible, as people who can’t use a mouse need to see what has keyboard focus. There is an AAA criterion which requires that there is no overlap at all, the focused item must be fully visible – 2.4.12 Focus Not Obscured (Enhanced) (AAA) Desktop only If component receives focus, it or its must not be completely hidden by author created content – e.g. cookie banner. Common components that may cause this – sticky footers, sticky headers, non-modal dialogs. If the component can be moved around, then only the initial position of the component is relevant. Testing demo Good example: https://www.bbc.co.uk/ (incognito window)- cookie banner does not obscure footer content and moves as focus moves down the page Bad example: https://www.ikea.com/ (incognito window)- cookie banner obscures link in footer
- For any action that involves dragging, a single pointer alternative is provided. This is important as some people can’t use a mouse or finger to drag items. Applies to things like drag and drop, sorting, sliders, moveable widget (chat window) Dragging movements covered in this Success Criterion are pointer interactions where only the start and endpoints matter. With drag and drop, you grab an element at one location (Point A) and then drop it somewhere else (Point B), but the path your pointer takes to get from A to B is not significant. Desktop and mobile. If dragging something is possible, an alternative must be provided (for example using a button to move the item from one place to another). This could also be in the form of a dropdown, with options. Or an input field where you can enter a value (colour wheel). Doesn’t have to be part of the same component. So how can this be tested? If dragging movement is required, look for single pointer alternative. Good example: https://www.mapquest.com/search/London - can drag map around. There are also buttons to complete the same functionality Bad example: https://www.google.com/maps/ - can drag map around. There is no single pointer option for this functionality Doesn’t apply if the dragging is essential (page scrolling) or for system level gestures (browser gestures) Different to Keyboard – Keyboard requires it can be operated with a keyboard. Dragging movements requires the drag can be achieved with a single pointer – applies to touch screen. Different to Pointer Gestures – functionality that requires custom gestures can be operated with a single pointer (eg tapping the screen). Testing demo BBC video - https://www.bbc.co.uk/news/av/world-us-canada-67552410 – scrolling vs buttons/single point on scroll
- Ensure targets meet a minimum size or have sufficient spacing around them, as some people cannot click/tap small buttons that are close together. Large number of exemptions for when the target is not 24px x 24px (it is undersized): Spacing – If there is sufficient spacing around the target Equivalent – Where an alternative target which meets the SC achieves the same functionality. Inline – Where the line-height of surrounding non-target text restricts the size of the targets. User agent control – The target size is determined by the user agent, not the author. E.g. radio button if not customised. Essential – The way the target is presented is essential or legally required. Desktop and mobile. Examples: https://bbc.co.uk/news/ - search icon button is 28px x 29px, well within the requirements. https://brightoncentre.co.uk/ - search icon button is only 16px x 16px. However, there is a margin of 16px encircling it, so it passes by virtue of the spacing exception
- Put help in the same place when it is on multiple pages, as people who need help can find it more easily if it is in the same place. Desktop and mobile. Doesn’t require help mechanisms are provided, but that when they are, they are located in the “same” place across a set of pages. “same” place – should be in the same relative order. For example, if it is programmatically in the footer on one page, it programmatically cant be in the header on another. What is a help mechanism? Help mechanisms, which can be on the page or via link to a different page, are: Human contact details – Email address, phone number, etc. Human contact mechanism – Live chat with a person Self-help option – FAQ page, “How do I” page, etc. A fully automated contact mechanism – Automated chatbot. Help can be on the page, or a direct link. If its human and only available at set times, user should be made aware of this. Also only applies to ‘set of pages’ – user journeys. Eg if youre on a news story and then directed to jobs site, then this is two separate journeys. NB: The “order” is restricted to the zoom level, viewport, orientation, etc, e.g. if it changes when viewed on a mobile device, rather than a desktop site, this is considered a change initiated by the user and is out of scope. Examples: https://www.gov.uk/ - help in the footer. https://www.currys.co.uk/ - live chat in bottom right – sticky. https://www.ikea.com/gb/en/ - FAQ link in footer – when going to login, not there. Different journey. https://www.sainsburys.co.uk/ and https://www.sainsburys.co.uk/shop/gb/groceries – WOULD THIS PASS? Help centre different locations visually and programmatically
- Don’t ask for the same information twice in the same session, as some people with cognitive disabilities have difficulty remembering what they have entered before. Those using assistive technologies such as switch devices, speech input or other AT for people with mobility impairments appreciate the reduced input required. By making these processes easier via redundant entry, conversion rates for sign-ups, e-commerce and other transactions are likely to increase. Example methods for conformance: Autocomplete (browser autocomplete doesn’t count) Select from a dropdown (select a home/business address) Copy and paste Checkbox to populate previously entered data (billing address same as billing address) NB – the information doesn’t need to be stored. If the user closes the process and returns later, they can be asked to re-enter their information again. There are exemptions: When re-entry is essential (e.g. a memory game) The information is required to ensure the security of the content (e.g. **** for passcodes and not letting them be copied) The previously entered info is no longer valid. Desktop and mobile. Examples: “Use my shipping address” (Apple) Search results with search string available in the search input bar (AN site)
- Example 1: Allowing the billing address to be the same as the shipping address which has already been added by using a checkbox. (Apple store) Example 2: Summary of information added when buying pet insurance, the details of the pet and the user were presented with an edit button to change any errors (Tesco)
- Don’t make people solve, recall, or transcribe something to authorise a log in, payment, etc., as some people with cognitive disabilities cannot solve puzzles, memorise login details or retype one-time passcodes. What is a Cognitive Function Test? A task that requires the user to remember, manipulate, or transcribe information. Examples include, but are not limited to: memorization, such as remembering a username, password, set of characters, images, or patterns. The common identifiers name, e-mail, and phone number are not considered cognitive function tests as they are personal to the user and consistent across Web sites; transcription, such as typing in characters; use of correct spelling; performance of calculations; solving of puzzles. What is an authentication process? - Confirming identity – logging into an account (shopping, online banking), logging into device (PIN entry), verifying id (making a payment), recovering email/password (forgotten password) Alternative: Another authentication method that does not rely on a cognitive function test. QR code. Mechanism: A mechanism is available to assist the user in completing the cognitive function test. Support for password entry by password entry, ability to copy and paste, biometrics Object Recognition: The cognitive function test is to recognize objects. Select images that have certain objects Personal Content: The cognitive function test is to identify non-text content the user provided to the Web site. For example they’ve been asked to identify an image they’ve uploaded There is an AAA criterion which doesn’t allow object recognition or personal content to be used – 3.3.9 Accessible Authentication (Enhanced) (AAA)
- Good examples: Link via email – used for minimal security requirements. Use of a trusted device – e.g. an app on a mobile device which the user can use to confirm that they are attempting access their account, make a payment, etc. Biometric option – fingerprint/facial recognition. Object recognition/user provided content (e.g. using CAPTCHA) – this is at AA. At AAA this is not allowed. CAPTCHA passes if it relies on recognising objects/content from user. Doesn’t pass if required to transcribe a word/number, or do a test. Note that this criterion applies to every stage in an authentication process. OTP, PIN entry, email/password recovery. Doesn’t apply to initial registration stages. If using multi-factor authentication where an OTP might be sent to a device, it must be possible to copy and paste a passcode from the secondary device to the input field or, for example, an email to then send to the primary device for copy and pasting into the input field. How this happens is out the SC scope, it only requires that the passcode be copiable. There must also be enough time from the code being provided for the user to input it via whatever means is necessary for them. It isn’t necessary to provide ALL these options, the SC only requires that at one of these be made available. Wherever a cognitive function test is required there must be at least one method that passes. This is for every step of the authentication process. Give the user choice in how they receive information – email/text/phone call. Caveat for banks – it is difficult to meet accessible authentication AND the legal requirements for banks. These examples only cover the accessibility side, we can’t advise on the financial legalities. Examples: LinkedIn, Revoult and IKEA.
- Nationwide – Failure. Requires used to select from dropdown. Cannot be copied and pasted. Ebay – Would pass if allowed copy and paste and on a phone (code sent to phone number). Would have to paste into each field. Give the user choice in how they receive information – email/text/phone call. Lloyds – could pass, as could allow user to copy and paste. Wouldn’t need to pass if theres an alternative, such as FaceID. Captcha – Would pass, relies on object recognition. Captcha fails if it relies on remembering a word/number, or relies on more than just object recognition (eg maths sum) Hotels.com – Copy and paste – also alternative allowing for password instead.
- Autocomplete off also not sufficient (1.3.5 Identify Input Purpose)
- WCAG must be regularly revaluated to ensure it stays up to date with accessibility and technology advancements. Guidelines and outcomes will be more granular (more focused on desired results than the technical means to achieve them). New: Assertions: a formal claim of fact from a person or organisation that can be used to support conformance, for example the implementation of a procedure such as training, usability testing or assistive technology testing. Most recent draft was released on 24th July 2023, it is not expected to become a standard for several more years. Updated drafts will be released every 3-6 months.
- WCAG has some restrictions due to its highly technical, pass/fail nature. WCAG is only the beginning. Many solutions that meet WCAG compliance do not necessarily represent best practice for accessibility for all users. Example of best practice: the requirement for targets to be at least 24x24 CSS pixels passes WCAG 2.2, but the best practice would be at least 44x44 CSS pixels for maximum usability and accessibility.
- Jordan, a 55-year-old retired headmaster, lives with Parkinson's, a conditions that impact his movement, causes tremors in his hands and stiffness in his joints and muscles. It worsen throughout the day the more he moves. - Implementation of Focus Not Obscured helps Jordan as he regularly uses a keyboard to navigate and interact with web content because of his worsening tremors and the additional stress using a mouse places on his hand. He used to cook every week for his family but due to Parkinsons shifted from cooking to being a cook to kitchen mentor, teaching his recipes and techniques to family, to aid fostering stronger familial bonds. Jordans tremors lead to frequent keyboard mistakes and misclicks. For instance, a single misclick once erased hours of effort in building his grocery list when he pressed ‘Clear’ instead of ‘Check-out’ from a shopping cart. - Implementation of Target size (minimum) helps to minimise the likelihood of Jordan hitting the wrong button, especially when using his tablet. His attention span, affected by Parkinson's, makes it difficult to spot and correct minor typing errors, complicating routine tasks like booking doctor's appointments because he has to back-track and re-enter all information again if he makes a mistake. - Implementation of Redundant Entry – reduces the physical and mental effort of entering information twice. Using a tablet eases Jordan's struggles, yet obstacles like inaccessible password managers still hinder his experience. Physical limitations and the need to manage his energy levels - he perverse with online shopping when he can. But often he must resort to asking his family for help, and this affects his sense of value and self-esteem. - Implementation of Accessible Authentication mean that Jordan can manage his banking and other important tasks safely and independently.