From 95fe1703ef2a789b8ecef01925d4d1fc1f7161bd Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Sat, 11 Mar 2023 13:04:15 -0500 Subject: [PATCH 01/18] updates to Abstract, Intro, Normative, and the introduction to guidelines updates to Abstract, Intro, Normative, and the introduction to guidelines sections. Normative removed RFC2119 language. Guidelines removed references to Captions and Structured Content. --- guidelines/index.html | 42 ++++++++++++------------------------------ 1 file changed, 12 insertions(+), 30 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index 6e1c5fc5..22117e33 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -14,8 +14,6 @@

The W3C Accessibility Guidelines (WCAG) 3.0 provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. These guidelines address accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other web of things devices. They address various types of web content including static content, interactive content, visual and auditory media, and virtual and augmented reality. The guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

Each guideline in this standard provides information on accessibility practices that address documented user needs of people with disabilities. Guidelines are supported by multiple outcomes to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each outcome.

This specification is expected to be updated regularly to keep pace with changing technology by updating and adding methods, outcomes, and guidelines to address new needs as technologies evolve. For entities that make formal claims of conformance to these guidelines, several levels of conformance are available to address the diverse nature of digital content and the type of testing that is performed.

-

W3C Accessibility Guidelines 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [[WCAG22]] and previous versions, but does not deprecate these versions. WCAG 3.0 will incorporate content from and partially extend User Agent Accessibility Guidelines 2.0 [[UAAG20]] and Authoring Tool Accessibility Guidelines 2.0 [[ATAG20]]. - While there is a lot of overlap between WCAG 2.X and WCAG 3.0, WCAG 3.0 includes additional tests and different scoring mechanisms. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X. WCAG 3.0 does not supersede WCAG 2.2 and previous versions; rather, it is an alternative set of guidelines. Once these guidelines become a W3C Recommendation, the W3C will advise developers, content creators and policy makers to use WCAG 3.0 in order to maximize future applicability of accessibility efforts. However, content that conforms to earlier versions of WCAG continue to conform to those versions.

See WCAG 3 Introduction for an introduction and links to WCAG technical and educational material.

@@ -25,38 +23,28 @@

Introduction

The current proposal for WCAG 3 is made up of different parts and sections, including:

-
  • WCAG3
    • -
  • WCAG3 Explainer
    • -
  • Guideline How-tos
    • -
  • Outcomes
    • -
  • Methods
    • -
  • Functional categories
    • -
-

These parts and sections are inter-related and are continually being refined and updated as more sections are developed. Content is in various states of maturity. The status is marked at the top of each section (see 1.2 Section status levels). Each publication of WCAG 3 will include updates to some, but not necessarily every part and section. This process will facilitate quarterly updates, which provide opportunities for public review and comment throughout the evolution of the guidelines. As a result, the document is a work in progress. Content will evolve and there may be changes to layout and style that are not yet reflected in all parts of the present release and will be reflected in future releases. The parts and sections updated in this release are:

-
  • First draft of the WCAG3 Explainer, which takes explanatory material out of WCAG3 to improve usability.
    • -
  • New conformance section on user-generated content and the glossary definition of user-generated content. -
    • -
  • A new proposal revising the Methods template to address comments from the First Public Working Draft (FPWD). This proposal was done in partnership with the ACT task force.
    • -
+
  • Two different directions for determining WCAG3 conformance. The feedback from our first few drafts was extensive. We have changed our approach to what is required to meet WCAG3.
    • +
  • We removed old material that was not consistent with the new approach. It does not mean we will not include it eventually, but to eliminate confusion, we have removed material that is no longer consistent with our current proposals.
    • +
  • WCAG3 Guideline placeholders which are short summaries of what we envision for the migration of the WCAG 2.x success criteria.
    • + +

    Content is in various states of maturity. The status is marked at the top of each section (see 1.2 Section status levels).

Summary

The W3C Accessibility Guidelines (WCAG) 3.0 show ways to make web content accessible to people with disabilities. WCAG 3.0 is a newer standard than the Web Content Accessibility Guidelines (WCAG) 2.2. You may use WCAG 2.2 or the new standard.

-

What’s new in WCAG 3.0?

- +

What’s new in WCAG 3.0?

  • WCAG 3.0 includes the needs of people with more types of disabilities.
    • -
  • It includes mobile and desktop applications, along with web content.
    • -
  • It has new guidelines and new tests.
    • -
  • It has new scoring. Your site or product no longer has to pass 100% of the guidelines, as long as people with disabilities can use it.
    • +
  • We received a lot of feedback from our first drafts. We changed our approach to what is required to meet WCAG3.
    • +
  • We removed old material that was not consistent with the new approach. It does not mean we will not include it eventually, but to eliminate confusion, we have removed material that is no longer consistent with our current proposals.
    • +
  • We are not publishing an updated WCAG3 Explainer.
    • +
  • There are high level summaries of what we think the guidelines will be.

About WCAG 3.0

-

This introduction provides a brief background to WCAG 3.0. Detailed information about the structure of the guidelines and inputs into their development is available in the Explainer for W3C Accessibility Guidelines (WCAG) 3.0. That document is recommended reading for anyone new to WCAG 3.

This specification presents a new model and guidelines to make web content and applications accessible to people with disabilities. The W3C Accessibility Guidelines (WCAG) 3.0 support a wide set of user needs, use new approaches to testing, and allow frequent maintenance of guidelines and related content to keep pace with accelerating technology change. WCAG 3.0 supports this evolution by focusing on users’ functional needs. These needs are then supported by outcomes and technology-specific methods to meet those needs. 

-

Following these guidelines will make content more accessible to people with a wide range of disabilities, including accommodations for blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. Following these guidelines will also often make content more usable to users in general as well as accessible to people with disabilities.

WCAG 3.0 is a successor to Web Content Accessibility Guidelines 2.2 [[WCAG22]] and previous versions, but does not deprecate WCAG 2.X. It will also incorporate content from and partially extend User Agent Accessibility Guidelines 2.0 [[UAAG20]] and Authoring Tool Accessibility Guidelines 2.0 [[ATAG20]]. These earlier versions provided a flexible model that kept them relevant for over 10 years. However, changing technology and changing needs of people with disabilities have led to the need for a new model to address content accessibility more comprehensively and flexibly.

There are many differences between WCAG 2.X and WCAG 3.0. Content that conforms to WCAG 2.2 A & AA is expected to meet most of the minimum conformance level of this new standard but, since WCAG 3.0 includes additional tests and different scoring mechanics, additional work will be needed to reach full conformance. Since the new standard will use a different conformance model, the Accessibility Guidelines Working Group expects that some organizations may wish to continue using WCAG 2.X, while others may wish to migrate to the new standard. For those that wish to migrate to the new standard, the Working Group will provide transition support materials, which may use mapping and other approaches to facilitate migration.

@@ -88,7 +76,6 @@

Relationship to other W3C guidelines

  • WCAG 3.0 is not backward compatible with WCAG 2.0, ATAG 2.0, and UAAG 2.0.

    • For more details about differences from previous guidelines, see Appendix: Differences From WCAG 2.

    -

    This version of the guidelines includes an example method for ATAG (Author control of text alternatives) and UAAG ( Reflow of captions and other text in context). Future drafts of the guidelines will include additional examples of ATAG- and UAAG-related content.

    Goals and Requirements

    @@ -111,8 +98,7 @@

    Normative requirements

    In addition to this section, the Guidelines, Testing, and Conformance sections in WCAG 3.0 provide normative content and define requirements that impact conformance claims. Introductory material, appendices, sections marked as non-normative, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

    -

    The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [[RFC2119]].

    -

    Outcomes are normative. The working group is looking for feedback on whether the following should be normative or informative: guidelines, methods, critical errors, and outcome ratings.

    +

    Outcomes are normative. The working group is looking for feedback on whether the following should be normative or informative: guidelines and methods.

    @@ -120,11 +106,9 @@

    Normative requirements

    Guidelines

    Summary -

    The following six guideline examples show different features of WCAG 3.0:

    +

    The following guideline examples show different features of WCAG 3.0:

    @@ -144,8 +128,6 @@

    Guidelines

    From 4c3fb74eb7c4df3efb1abf1eccff5c446c8def1e Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 5 Apr 2023 09:52:59 -0400 Subject: [PATCH 02/18] Intro to Conformance including BB reformat. --- guidelines/index.html | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index 7f703a7c..afaa93ae 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -219,23 +219,32 @@

    Conformance

    You might want to make a claim that your content or product meets the WCAG 3.0 outcomes. If it does meet the outcomes, we call this “conformance.” To conform to WCAG 3.0, your test results must show that your project is accessible.

    If you want to make a conformance claim, you must use the process described in this document. However, conformance claims are not required and your content can conform to WCAG 3.0, even if you don’t want to make a claim. You can still use this process to test your project’s accessibility.

    -

    WCAG 3.0 will include a new conformance model in order to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. There are several key goals for this new conformance model:

    1. Develop a model that encourages websites to continue to do better and better (vs. stopping at the previous AA level);
    2. Better reflect the lived experience of people with disabilities, who successfully use sites that have some content that does not meet WCAG 2.0 AA, or who encounter barriers with sites that meet WCAG 2.0 AA;
      3. -
    3. Allow for bugs and oversight by content authors, provided the impact of them is limited to users with disabilities.
      4. +
    4. Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.
    +

    We are exploring several approaches to conformance. After studying the comments on the previous draft, these are the concepts that showed promise. We are giving an overview in this draft, but we continue to test the combination of the concepts.

    +

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options in late 2023 based on feedback, prototyping, and testing.

    +

    There are two main approaches to evaluating conformance that are promising. There are also detailed ideas that support the main approaches. The two main approaches are:

    +
      +
    • Outcomes, quantifiable and qualitative tests, and conditions: +
      • Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. All Outcomes and Assertions that relate to a Guideline will be listed together to encourage adoption of higher levels of accessibility.
        • +
      • Quantifiable tests rely on measuring properties of the content based on nominal values. The test results are objectively verifiable, to avoid variation of test results between different testers.
      • Qualitative tests rely on evaluating content based on a set of defined expectations and exceptions. The set of expectations and exceptions limit the scope of decisions, to minimize variation of test results arrived at by different testers.
        • +
      • Both Quantitative and Qualitative tests can be conditional. These tests only apply in certain situations.
      • +
    • Assertions and Procedures: Assertions are attributable statements by a person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 4.2. +
    +

    There are additional ideas that support these two approaches and can be used or combined in many different ways.

    +
      +
    • Conformance levels: Bronze, Silver, and Gold levels continue to receive positive feedback as an approach for overall conformance rating.
      • +
    • Issue Severity: Outcomes may allow for the concept of varying severity. High severity issues are those which prevent users from completing user processes (tasks).
      • +
    • Adjectival Ratings: Adjectival Ratings allow testers to grade a test, outcome, or guideline by an adjective rating (such as fail, pass, exemplary) or a numeric rating (such as 1-5) that potentially can be closer to the lived experience of a person with a disability.
      • +
    • Pre-assessment conditions: Pre-Assessment checks are tests or criteria that implementers can use to determine if they are ready to assess conformance. The intent is to help organizations prepare for conformance testing, not to create a new level of conformance.
      • +
    +

    The details of these approaches change as we assemble them into a coherent whole. This draft gives a high level overview of these approaches so we can give an update and receive feedback on the individual approaches we are considering.

    -

    We are exploring two options and encourage feedback about which aspects and approaches will be beneficial and which will not. We also seek feedback on the conformance approach as a whole.

    -
    - -

    WCAG 3.0 defines outcomes and assertions.

    -

    Outcomes are written as testable statements that allow testers to reliably determine if the content being evaluated satisfies the criteria. Only outcomes can be tested independently. Outcomes are addressed in Section 4.1.

    - - -

    Assertions are attributable statements by person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 4.2.

    Outcomes

    From d3f96ef159d84251b1e0b9245fefb1fb6708031b Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 5 Apr 2023 18:32:22 -0400 Subject: [PATCH 03/18] finished Google doc comments Most survey comments are not yet included. --- guidelines/index.html | 315 ++++++++++++++++++++---------------------- 1 file changed, 152 insertions(+), 163 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index afaa93ae..2b8c3063 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -222,7 +222,7 @@

    Conformance

    WCAG 3.0 will include a new conformance model in order to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. There are several key goals for this new conformance model:

      -
    1. Develop a model that encourages websites to continue to do better and better (vs. stopping at the previous AA level);
      2. +
    2. Develop a model that encourages websites to continue to improve accessibility (vs. stopping at the previous AA level);
    3. Better reflect the lived experience of people with disabilities, who successfully use sites that have some content that does not meet WCAG 2.0 AA, or who encounter barriers with sites that meet WCAG 2.0 AA;
    4. Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.
    @@ -230,11 +230,8 @@

    Conformance

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options in late 2023 based on feedback, prototyping, and testing.

    There are two main approaches to evaluating conformance that are promising. There are also detailed ideas that support the main approaches. The two main approaches are:

      -
    • Outcomes, quantifiable and qualitative tests, and conditions: -
      • Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. All Outcomes and Assertions that relate to a Guideline will be listed together to encourage adoption of higher levels of accessibility.
        • -
      • Quantifiable tests rely on measuring properties of the content based on nominal values. The test results are objectively verifiable, to avoid variation of test results between different testers.
      • Qualitative tests rely on evaluating content based on a set of defined expectations and exceptions. The set of expectations and exceptions limit the scope of decisions, to minimize variation of test results arrived at by different testers.
        • -
      • Both Quantitative and Qualitative tests can be conditional. These tests only apply in certain situations.
      • -
    • Assertions and Procedures: Assertions are attributable statements by a person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 4.2. +
    • Outcomes and Tests: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. Tests are addressed in Section 4.2.
      • +
    • Assertions and Procedures: Assertions are attributable statements by a person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 4.3.

    There are additional ideas that support these two approaches and can be used or combined in many different ways.

      @@ -247,11 +244,26 @@

      Conformance

      Outcomes

      +
      + Summary +

      To be written once content is agreed on.

      +
      +
      +

      To be written when we sort out the Outcome questions.

      +
      +

      Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. All Outcomes and Assertions that relate to a Guideline will be listed together to encourage adoption of higher levels of accessibility.

      +

      Each outcome is associated with at least one method. Each method contains explanation, examples, resources, and sets of tests for meeting the outcome. Methods can apply to a specific technology, such as HTML, or can be more generic where the advice applies no matter what technology, such as the methods supporting the Clear Language guideline.

      + +

      Outcomes are written so that testers can test the accessibility of new and emerging technologies based solely on the outcome, even when methods do not yet exist for those technologies.

      +
      + +
      +

      Tests

      What types of tests and scopes are used?

      WCAG 3.0 includes two (2) types of tests which are evaluated:

        -
      • Quantitative tests: Tests where results will not vary based on the tester or approach. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
        • +
      • Quantifiable tests: Tests where results will not vary based on the tester or approach. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
      • Qualitative tests: Tests that rely on a qualitative evaluation based on existing criteria. Test results may vary between testers who understand the criteria. An example is evaluating the quality of a requirement such as alternative text.
      @@ -266,6 +278,7 @@

      Outcomes

      +

      This editor note needs to be rewritten to reflect the new proposals.

      As we continue developing this content, we seek input on the following:

      - -

      Each outcome includes methods associated with different technologies. Each method contains techniques and sets of tests for meeting the outcome.

      - -

      Outcomes are written so that testers can test the accessibility of new and emerging technologies based solely on the outcome, even when methods do not yet exist for those technologies.

      -
      -

      Test scopes

      -

      Testing outcomes use items, views, user processes, and the aggregate to define what is being tested.

      - -

      Items are the smallest testable unit. They may be interactive components such as a drop down menu, a link, or a media player. They may also be units of content such as a word, a phrase, a label or error message, an icon, or an image.

      - -

      Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2.X, but are not restricted to content meeting that definition. For example, a view could be considered a "screen" in a mobile app or a layer of web content – such as a modal.

      - -

      User processes are a series of user actions, and the distinct interactive views and items that support the actions, where each action is required in order to complete an activity. A user process may include a subset of items in a view or a group of views.

      -

      Examples of a process include:

      -
        -
      • Logging into a site and being recognized as an authenticated user;
        • -
      • Ordering an item, in which case the process includes the entire set of tasks from searching for the item, adding it to the shopping cart, paying for it, and receiving confirmation;
        • -
      • Submitting tax information, from start to end of the process; and
        • -
      • Interacting with other users in a virtual reality environment.
        • -
      -

      A process is comprised of one or more views or subsets of views. Only the part of the views that support the user process are included in a test of the user process.

      - -

      The aggregate is the combination of items, views, and user processes that collectively comprise the site, set of web pages, web app, etc.

      -
      -

      Types of tests

      WCAG 3.0 includes two (2) types of tests which are evaluated:

        -
      • Quantitative tests: Tests where results will not vary based on the tester or approach. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
        • +
      • Quantifiable tests: Tests where results will not vary based on the tester or approach. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
      • Qualitative tests: Tests that rely on a qualitative evaluation based on existing criteria. Test results may vary between testers who understand the criteria. One example is evaluating the quality of alternative text used to meet a requirement for alternative text.

      Most tests have prescribed ways to meet the test. In some cases, the ways to meet the test will change based on a specific condition being met (example: the language the content is written in).

      -

      Although content may satisfy all outcomes using quantitative and qualitative tests, the content may not always be usable by people with a wide variety of disabilities. The assertions (see 4.2 below) are designed to address this problem.

      +

      Although content may satisfy all outcomes using quantifiable and qualitative tests, the content may not always be usable by people with a wide variety of disabilities. The assertions (see section 4.3 below) are designed to address this problem.

      -
      Quantitative tests
      -

      Quantitative tests rely on measuring properties of the content based on nominal values. The test results are objectively verifiable, to avoid variation of test results between different testers. Values are quantitative, and could be boolean (true/false), for example to check the presence of titles, text alternatives, and accessible names. Other values could include numerical thresholds; for example, to check color luminosity ratios.

      -

      Each method using quantitative tests includes:

      +
      Quantifiable tests
      +

      Quantifiable tests rely on measuring properties of the content based on nominal values. The test results are objectively verifiable, to avoid variation of test results between different testers. Values are quantifiable, and could be boolean (true/false), for example to check the presence of titles, text alternatives, and accessible names. Other values could include numerical thresholds; for example, to check color luminosity ratios.

      +

      Each method using quantifiable tests includes:

      • the values being tested; and
      • an algorithm to measure the properties of the content based on the values.
      - -
      -
      -

      Conditions

      -

      Some tests only apply in certain situations. Testing may occasionally require determining and referencing which specifications are being tested against. Methods will note whether a test always applies or under what conditions a test applies. Both Quantitative and Qualitative tests can be conditional.

      +
      +
      +

      Test scopes

      +

      Testing outcomes use items, views, user processes, and the aggregate to define what is being tested.

      + +

      Items are the smallest testable unit. They may be interactive components such as a drop down menu, a link, or a media player. They may also be units of content such as a word, a phrase, a label or error message, an icon, or an image.

      + +

      Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2.X, but are not restricted to content meeting that definition. For example, a view could be considered a "screen" in a mobile app or a layer of web content – such as a modal.

      + +

      User processes are a series of user actions, and the distinct interactive views and items that support the actions, where each action is required in order to complete an activity. A user process may include a subset of items in a view or a group of views.

      +

      Examples of a process include:

      +
        +
      • Logging into a site and being recognized as an authenticated user;
        • +
      • Ordering an item, in which case the process includes the entire set of tasks from searching for the item, adding it to the shopping cart, paying for it, and receiving confirmation;
        • +
      • Submitting tax information, from start to end of the process; and
        • +
      • Interacting with other users in a virtual reality environment.
        • +
      +

      A process is comprised of one or more views or subsets of views. Only the part of the views that support the user process are included in a test of the user process.

      + +

      The aggregate is the combination of items, views, and user processes that collectively comprise the site, set of web pages, web app, etc.

      +
      +
      +

      Conditions

      +

      Some tests only apply in certain situations. Testing may occasionally require determining and referencing which specifications are being tested against. Methods will note whether a test always applies or under what conditions a test applies. Both Quantitative and Qualitative tests can be conditional.

      -

      As we develop example outcomes and methods, we want to explore conditions overall and how multiple measurements fit in. We welcome comments on allowing alternative measurements to meet an outcome.

      +

      As we develop example outcomes and methods, we want to explore conditions overall and how multiple measurements fit in. We welcome comments on allowing alternative measurements to meet an outcome.

    -
    - -
    -

    Critical Issues

    - -
    -

    This section is exploratory. -

    Severity rating could contribute towards scoring and prioritization.

    -

    As we continue developing this content, we seek input on the following:

    -
      -
    1. Is every issue critical to someone, making this concept invalid?
      2. -
    2. What to do with non-critical issues?
      3. -
    3. How best to assign severity, particularly if testers have different ideas on what is critical?
      4. -
    4. How do we incorporate context/process/task? Is that part of scoping, or issue severity? Both are important to the end result.
      5. -
    5. If included, how will situations where severity depends on context be handled?
      6. -
    6. Can the matrix inform designation of functional categories? For example, the Text Alternative Available outcome.
      7. -
    7. How will issue severity fit into levels? For example:
        -
      • "Bronze" could be an absence of any critical or high issues;
        • -
      • "Silver" could be an absence of any critical, high, or medium issues.
        • -
      -
      8. -
    8. How to account for cumulative issues becoming critical?
      9. -
    9. Would another approach be more effective, for example assigning critical issues after testing is complete based on task or type of task rather than by test.
      10. -
    -
    - -

    Tests will include critical issues. Each test will have a category of severity, so some tests will be flagged as causing a critical issue. Examples of critical issues in tests are at Text Alternative Available and Translates Speech And Non-Speech Audio.

    -
    - -
    -

    Scoring

    -
    -

    This section is exploratory. We are exploring two approaches to scoring and levels which are labeled Option 1 and Option 2. We continue to test these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria.The working group plans to select or even replace these options in late 2023 based on feedback, prototyping, and testing.

    -

    As we continue developing this content, we seek input on the following:

    -
      -
    • How well does scoring support the need for equity across disability types?
      • -
    -

    Next steps include:

    -
    • Writing sample outcomes to explore each option and how to handle aggregating scores
      • -
    • Testing each option for validity, reliability, sensitivity, adequacy, and complexity.
      • -
    -
    -
    -
    Option 1: Pass/Fail
    -

    Outcomes will be scored as Pass or Fail.

    -

    Some outcomes include methods which are not required. These "best practice" methods are stricter than those required to pass. -

    -
    -
    Option 2: Pass/Fail/Exemplary
    -

    Outcomes will be scored as Fail, Pass, or Exemplary. "Exemplary" meets stricter requirements than those needed to Pass.

    -
    -
    - - - - + +

    Assertions and Procedures

    Summary -

    @@

    +

    To be written once we agree on what goes in this section.

    This section is exploratory.

    As we continue developing this content, we seek input on the following:

    @@ -442,13 +395,14 @@

    Assertions and Procedures

  • Can assertions be used to record accessibility work that is not required in the guidelines? This could include advance work on guidance not yet added to the guidelines.
    • -
  • What optional supporting documentation should organizations provide?
    • +
  • What optional supporting documentation should organizations provide with an assertion?
  • Is there a need for WCAG 3.0 to require proof of an assertion, and if so, what documentation should be required as proof?
  • Should assertions be dated, expire, or be reviewed on a regular basis?
  • Can steps in a procedure duplicate tests in other parts of the guidelines? If so, how should those be handled?
  • Can assertions exist outside of conformance? For example, can they be used as an internal benchmark rather than for a claim of conformance?
  • Can assertions be used at the most basic level of conformance? If so, how?
  • How can small organizations use assertions without unrealistic burden?
    • +
  • The AGWG is considering whether and how assertions can be applied to the Bronze level.

    • Next steps include:

    • Better define procedure,
      • @@ -458,27 +412,16 @@

      Assertions and Procedures

      Assertions

      -

      An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3, an assertion is an attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility. Assertions are only testable in that one can test that the assertion has been made correctly - not that any desired result has occurred. The results are always true/false.

      +

      An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3, an assertion is an attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility. Testing of an assertion is always true/false — did they make an assertion and provide the required documentation?

      WCAG 3 recommends supporting documentation that an organization can use to improve or validate procedures and assertions. Conforming does not require this supporting documentation be made public.

      Using Assertions

      -

      Assertions may supplement methods in one or more outcomes. Assertions should only be used on outcomes and guidelines that allow assertions. Organizations can make an assertion that they followed a procedure to claim conformance at the Silver or Gold level.

      - +

      Assertions may supplement methods in one or more outcomes. Assertions should only be used on outcomes and guidelines that allow assertions. Organizations can make an assertion that they followed a procedure to claim conformance.

      -

      The AGWG is considering whether and how assertions can be applied to the Bronze level.

      - -

      Procedures used in assertions may be implemented during implementation or as part of evaluation.

      - -
      -

      The AGWG is considering what will qualify as a procedure in WCAG 3. A procedure may be limited to guidance: -

      • approved by AGWG and listed in WCAG,
        • -
      • that references publicly published guidance, or
        • -
      • that meets criteria specified in WCAG
      - or it may be any process that an organization uses to improve accessibility.

      -
      +

      Procedures used in assertions may be implemented at the organization level, during design and development, or during testing

      Examples of procedures that may be used during implementation might include:

      • Training
        • @@ -490,7 +433,14 @@

        Using Assertions

        Examples of procedures that may be used to evaluate accessibility might include:

        • Usability testing
        • Heuristic evaluation
          • -
        • Screen reader testing
        +
      • Assistive technology testing
      +
      +

      The AGWG is considering what will qualify as a procedure in WCAG 3. A procedure may be limited to guidance: +

      • approved by AGWG and listed in WCAG,
        • +
      • that references publicly published guidance, or
        • +
      • that meets criteria specified in WCAG
      + or it may be any process that an organization uses to improve accessibility.

      +
      @@ -510,26 +460,26 @@

      Documenting Assertions

      -

      Supporting Documentation

      -

      WCAG recommends additional information that can support procedures. WCAG will not require organizations to provide supporting documentation to conform.

      +

      Supporting Documentation for Assertions

      +

      WCAG recommends maintaining additional information that can support procedures. WCAG will not require organizations to provide supporting documentation to conform.

      The AGWG will add to this section as other areas are confirmed.

      Testing Assertions

      -

      The quality of an assertion can be tested based on how well the assertion meets the documentation requirements for assertions (See Documenting Assertions). Conforming to WCAG does not require testing supporting documentation; however, organizations may decide to adopt additional documentation requirements based on the procedure being asserted.

      +

      The quality of an assertion can be tested based on how well the assertion meets the documentation requirements for assertions (See Documenting Assertions). Conforming to WCAG does not require testing supporting documentation; however, organizations may decide to adopt additional documentation requirements based on the procedure being asserted.

      - -
    +

    Conformance levels

    -

    This section is exploratory. We are exploring two approaches to scoring and levels which are labeled Option 1 and Option 2. We continue to test these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria.The working group plans to select or even replace these options in late 2023 based on feedback, prototyping, and testing.

    +

    This section is exploratory. We are exploring several approaches to conformance. These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options in late 2023 based on feedback, prototyping, and testing.

    +

    While there is a lot of overlap between WCAG 2 and WCAG 3, WCAG 3 will include additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

    +

    The percentages used are placeholders and will need to be determined through testing. As we continue developing this content, we seek input on the following:

    • Which option has the best chance of adoption and why?
      • -
    • How can percentages be used in a way that is equitable across disabiliites?

    Next steps include

      @@ -539,49 +489,86 @@

      Conformance levels

    -

    WCAG 3.0 defines three levels of conformance: bronze, silver, and gold.

    -
    -

    Bronze

    -

    Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3.0.

    +

    WCAG 3.0 defines three levels of conformance: bronze, silver, and gold. While it is easy to replicate the WCAG2 A, AA, AAA by renaming the levels, there is an opportunity to improve accessibility for people with disabilities by using a more advanced approach.

    +

    Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3.0. In order to reach Bronze level, the scope claimed in the conformance statement must pass a subset of Outcomes and Assertions. The subset will require enough Outcomes and Assertions to improve equity across functional needs.

    -

    All required Outcomes pass.

    - -

    While there is a lot of overlap between WCAG 2 and WCAG 3, WCAG 3 includes additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

    +

    Silver level incentivizes organizations to go further to improve accessibility. One possibility that we are examining is that Silver level points can accumulate even prior to completing bronze but are not usable until Bronze is achieved. The goal is to encourage organizations to go beyond the minimum, especially where organizations want to be recognized for their efforts to go beyond minimum accessibility.

    + +

    Gold level identifies measures we want to include for those organizations that do achieve Silver so that some can stand out as exemplary, cutting edge, and role models. There are a number of ideas that will be developed further once more of the conformance structure is solidified.

    +
    +
    +

    Issue Severity

    +
    +

    This section is exploratory.

    +

    Severity rating could contribute towards scoring and prioritization.

    +

    As we continue developing this content, we seek input on the following:

    +
      +
    1. Is every issue critical to someone, making this concept invalid?
      2. +
    2. How best to assign severity, particularly if testers have different ideas on what is critical?
      3. +
    3. How do we incorporate context/process/task? Is that part of scoping, or issue severity? Both are important to the end result.
      4. +
    4. What to do with non-critical issues?
      5. +
    5. If included, how will situations where severity depends on context be handled?
      6. +
    6. Can the matrix inform designation of functional categories? For example, the Text Alternative Available outcome.
      7. +
    7. How will issue severity fit into levels? For example:
        +
      • "Bronze" could be an absence of any critical or high issues;
        • +
      • "Silver" could be an absence of any critical, high, or medium issues.
        • +
      +
      8. +
    8. How to account for cumulative issues becoming critical?
      9. +
    9. Would another approach be more effective, for example assigning critical issues after testing is complete based on task or type of task rather than by test.
      10. +
    +

    Next steps include:

    +
      +
    • Testing the assumption that some failures cause a greater impact to users than others.
      • +
    • Explore whether the concept of issue severity can be applied consistently and effectively.
      • +
    +
    +

    Outcomes may allow for the concept of varying severity. High severity issues are those which prevent users from completing user processes (tasks).

    +

    Tests could include critical issues. Each test could have a category of severity, so some tests will be flagged as causing a critical issue. Examples of critical issues in tests are at Text Alternative Available and Translates Speech And Non-Speech Audio.

    -
    -

    Silver

    -

    Silver is a higher conformance level than Bronze.

    -
    -
    Option 1: Pass/Fail
    - -
    -
    -
    Option 2: Pass/Fail/Exemplary
    -
    • Passes Bronze and
      • -
    • 50% of Outcomes score Exemplary.
    -
    + +
    +

    Adjectival Ratings

    +
    +

    This section is exploratory.

    +
    +

    Adjectival Ratings allow test results to go beyond Pass or Fail to show progress towards a goal or exceeding a goal. Example of Possible adjectival ratings are:

    +
      +
    • Fail, Pass, Exceptional
      • +
    • Fail, Progress, Pass, Better, Exceptional
      • +
    +

    Outcomes or Guidelines could be evaluated using adjectival ratings:

    +
      +
    • This includes both directly Testable outcomes and Qualitative measures that are asserted.
      • +
    • Outcomes might be assigned an adjectival rating based on methods used to meet the outcome and issue severity
      • +
    • Guidelines might be assigned an adjectival rating based on the outcomes and assertions completed under the guideline.
      • +
    -
    -

    Gold

    -

    Gold is the highest conformance level.

    -
    -
    Option 1: Pass/Fail
    -
    • Passes Bronze and
      • -
    • 75% of best practices pass (25% more than Silver).
    -

    A way to integrate assertions would be needed

    -
    -
    -
    Option 2: Pass/Fail/Exemplary
    -
    • Passes Bronze and
      • -
    • 75% of outcomes pass score Exemplary (25% more than Silver).
      • -

      A way to integrate assertions would be needed

      -
    -
    -
    + +
    +

    Percentages

    +
    +

    This section is exploratory.

    +

    We are exploring whether percentages could apply to Bronze but have not found a model to date where this works without adding complexity and time needed for testing.

    +

    As we continue developing this content, we seek input on the following:

    +
      +
    • How can percentages be used in a way that is equitable across disabilities?
      • +
    +
    +

    In this approach, percentage of Outcomes and Assertions passed or percentage passed at a certain adjectival rating might be used to conform to Silver and Gold levels.

    -
    - + +
    +

    Pre-Assessment Checks

    +
    +

    This section is exploratory.

    +
    +

    Pre-Assessment checks are tests or criteria that implementors can use to determine if they are ready to assess conformance. The intent of specifying these would be to help implementors prepare for conformance testing, not to create a new level of conformance. Examples of pre-assessment checks might be:

    +
      +
    • The video player used has the ability to display captions and support multiple audio tracks
      • +
    • All non-text elements on a page have an accessible name
      • +
    +

    User generated content

    @@ -670,6 +657,8 @@

    Example conformance claim

    Glossary

    Many of the terms defined here have common meanings. When terms appear with a link to the definition, the meaning is as formally defined here. When terms appear without a link to the definition, their meaning is not explicitly related to the formal definition here. These definitions are in progress and may evolve as the document evolves.

    +
    Adjectival Ratings
    +

    A system to report evaluation results as a set of human-understandable adjectives.

    Assertion

    A formal claim of fact, attributed to a person or organization. An attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility.

    Automated From 8e8f57628c34a97630e7adce3178c317aa55658b Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 5 Apr 2023 19:06:26 -0400 Subject: [PATCH 04/18] Added glossary definitions and links --- guidelines/index.html | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index 2b8c3063..23def2eb 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -227,7 +227,7 @@

    Conformance

  • Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.

    • We are exploring several approaches to conformance. After studying the comments on the previous draft, these are the concepts that showed promise. We are giving an overview in this draft, but we continue to test the combination of the concepts.

    -

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options in late 2023 based on feedback, prototyping, and testing.

    +

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options in late 2023 based on feedback, prototyping, and testing.

    There are two main approaches to evaluating conformance that are promising. There are also detailed ideas that support the main approaches. The two main approaches are:

    • Outcomes and Tests: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. Tests are addressed in Section 4.2.
      • @@ -657,7 +657,11 @@

      Example conformance claim

      Glossary

      Many of the terms defined here have common meanings. When terms appear with a link to the definition, the meaning is as formally defined here. When terms appear without a link to the definition, their meaning is not explicitly related to the formal definition here. These definitions are in progress and may evolve as the document evolves.

      -
      Adjectival Ratings
      +
      Adequacy
      +
      +

      Adequacy is subtle metric, but important to WCAG3 proposals. Adequacy describes if the formulas being used to process and score the accessibility testing results are using such a small interval that small changes in accessibility do not cause large changes in scoring. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +
      +
      Adjectival Ratings

      A system to report evaluation results as a set of human-understandable adjectives.

      Assertion

      A formal claim of fact, attributed to a person or organization. An attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility.

      @@ -671,6 +675,10 @@

      Glossary

      machine learning is not included in this definition.

      Best Practice

      Methods which are not required and meet a higher requirement than methods required to conform to Bronze.

      +
      Complexity
      +
      +

      Complexity refers to the resources required to accomplish the conformance testing. These could be crawler time, or time for human judgment testing. This would be a useful metric to have to answer the question of how much time WCAG3 takes to test as compared to WCAG 2.x. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +
      Conformance

      Satisfying all the requirements of the guidelines. Conformance is an important part of following the guidelines even when not making a formal Conformance Claim.

      @@ -680,6 +688,10 @@

      Glossary

      To declare something outdated and in the process of being phased out, usually in favor of a specified replacement.

      Deprecated documents are no longer recommended for use and may cease to exist in the future.

      +
      Equity
      +
      +

      Equity is the outcome of processes and actions that ensure the spectrum of human reality obtains what is needed to participate, not solely access. As equity relates to WCAG it is about the impact the standards/guidelines have on people with disabilities, along with actually including PWD in the work. (This definition needs updating as the Equity group does more work. This definition came from the Equity subgroup of AGWG in Q2 2022)

      +
      Evaluation
      The process of examining content for conformance to these guidelines.
      @@ -728,6 +740,11 @@

      Glossary

      Process

      A sequence of steps that need to be completed in order to accomplish an activity / task from end-to-end.

      +
      Reliability
      +
      +

      The reproducibility and consistency of scores i.e. the extent to which they are the same when evaluations of the same resources are carried out in different contexts (different tools, different people, different goals, different time). This would be particularly useful to ensure that similar results are achieved by different testers. It would also be useful to see if different testers would select the same path or off-path decisions. Representative sampling tests also fit in this category. + Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +
      Semi-Automated Evaluation

      Evaluation conducted using machines to guide humans to areas that need @@ -735,6 +752,10 @@

      Glossary

      Semi-automated evaluation involves components of automated evaluation and human evaluation.

      +
      Sensitivity
      +
      +

      Sensitivity of a metric is related to the extent that changes in the output of the metric are quantitatively related to changes of the accessibility of the site being analyzed. This metric is useful for determining if the conformance proposal captures the impact of the severity of accessibility barriers on the final score and if different disabilities are treated equally by the proposal. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +
      Set of Tests

      A group of tests that supports a method.

      @@ -754,6 +775,10 @@

      Glossary

      Evaluation of content by observation of how users with specific functional needs are able to complete a process and how the content meets the relevant outcomes.

      +
      Validity
      +
      +

      The extent to which the measurements obtained by a metric reflect the accessibility of the website to which it is applied. Does the rating that a web site or digital product achieve in any conformance proposal actually reflect the rating that it should get? Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011. Accessed on 29 July 2020

      +
    From 2fda4d2b6cc1c643adc7b112bf4b9c37316a5390 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 5 Apr 2023 19:13:47 -0400 Subject: [PATCH 05/18] updates from the survey --- guidelines/index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index 23def2eb..47ccec03 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -329,11 +329,11 @@
    Example quantifiable test
    Qualitative tests
    -

    Qualitative tests rely on evaluating content based on a set of defined expectations and exceptions. The set of expectations and exceptions limit the scope of decisions, to minimize variation of test results arrived at by different testers. Still, some level of qualitative assessment is required, therefore the accuracy of the test results also depends on the knowledge and context of the testers to some degree.

    +

    Qualitative tests rely on evaluating content based on a set of defined qualities and exceptions. The set of qualities and exceptions limit the scope of decisions, to minimize variation of test results arrived at by different testers. Still, some level of qualitative assessment is required, therefore the accuracy of the test results also depends on the knowledge and context of the testers to some degree.

    Each method using qualitative tests includes:

      -
    • the defined expectations being tested; and
      • -
    • guidance on evaluating how well the content meets the defined expectations.
      • +
    • the defined qualities being tested; and
      • +
    • guidance on evaluating how well the content meets the defined qualities.
    @@ -263,7 +263,7 @@

    Tests

    What types of tests and scopes are used?

    WCAG 3.0 includes two (2) types of tests which are evaluated:

      -
    • Quantifiable tests: Tests where results will not vary based on the tester or approach. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
      • +
    • Quantifiable tests: Tests where there is a high degree of consistency between test results from different testers. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
    • Qualitative tests: Tests that rely on a qualitative evaluation based on existing criteria. Test results may vary between testers who understand the criteria. An example is evaluating the quality of a requirement such as alternative text.
    @@ -301,7 +301,7 @@

    Tests

    Types of tests

    WCAG 3.0 includes two (2) types of tests which are evaluated:

      -
    • Quantifiable tests: Tests where results will not vary based on the tester or approach. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
      • +
    • Quantifiable tests: Tests where there is a high degree of consistency between test results from different testers. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
    • Qualitative tests: Tests that rely on a qualitative evaluation based on existing criteria. Test results may vary between testers who understand the criteria. One example is evaluating the quality of alternative text used to meet a requirement for alternative text.
    @@ -474,7 +474,7 @@

    Testing Assertions

    Conformance levels

    -

    This section is exploratory. We are exploring several approaches to conformance. These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options in late 2023 based on feedback, prototyping, and testing.

    +

    This section is exploratory. We are exploring several approaches to conformance. These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

    While there is a lot of overlap between WCAG 2 and WCAG 3, WCAG 3 will include additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

    From 26ba267305ad3216052d4e5f8e82f67800c4dc26 Mon Sep 17 00:00:00 2001 From: rachaelbradley Date: Fri, 7 Apr 2023 21:22:59 -0400 Subject: [PATCH 07/18] Slight updates --- guidelines/index.html | 71 +++++++++++++++++++++---------------------- 1 file changed, 35 insertions(+), 36 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index b72419a6..9923cd8c 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -1,4 +1,4 @@ - + W3C Accessibility Guidelines (WCAG) 3.0 @@ -227,11 +227,11 @@

    Conformance

  • Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.

    • We are exploring several approaches to conformance. After studying the comments on the previous draft, these are the concepts that showed promise. We are giving an overview in this draft, but we continue to test the combination of the concepts.

    -

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these optionsbased on feedback, prototyping, and testing.

    -

    There are two main approaches to evaluating conformance that are promising. There are also detailed ideas that support the main approaches. The two main approaches are:

    +

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

    +

    There are two main approaches to evaluating accessibility that are promising. There are also detailed ideas that support these approaches. The two main approaches are:

      -
    • Outcomes and Tests: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. Tests are addressed in Section 4.2.
      • -
    • Assertions and Procedures: Assertions are attributable statements by a person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 4.3. +
    • Outcomes with Tests: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. Tests are addressed in Section 4.1.1.
      • +
    • Assertions and Procedures: Assertions are attributable statements by a person or organization that they followed a procedure to improve accessibility. Assertions are addressed in Section 4.2.

    There are additional ideas that support these two approaches and can be used or combined in many different ways.

      @@ -242,8 +242,27 @@

      Conformance

    The details of these approaches change as we assemble them into a coherent whole. This draft gives a high level overview of these approaches so we can give an update and receive feedback on the individual approaches we are considering.

    +
    +

    As we continue developing this content, we seek input on the following:

    +
      +
    • How well does the approach to outcomes, assertions and tests defined here support additional requirements not addressed in 2.2?
      • +
    • How well does this approach support regulatory needs?
      • +
    • How will these approaches be integrated into a conformance model (including levels or scores)?
      • +
    • As written, outcomes and assertions are at the same level. Would moving assertions to the test level be more effective?
      • +
    +

    Next steps include:

    +
      +
    • Get feedback from designers, developers, and other communities on wording choice.
      • +
    • Finalize names and descriptions of scope and tests,
      • +
    • Develop detailed examples of methods and test,
      • +
    • Test the accuracy, reliability, repeatability, etc. of this various models using these approaches,
      • +
    • Address all github issues under test types and terminology milestone.
      • +
    +
    + +
    -

    Outcomes

    +

    Outcomes

    Summary

    To be written once content is agreed on.

    @@ -252,13 +271,12 @@

    Outcomes

    To be written when we sort out the Outcome questions.

    Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. All Outcomes and Assertions that relate to a Guideline will be listed together to encourage adoption of higher levels of accessibility.

    -

    Each outcome is associated with at least one method. Each method contains techniques for meeting the outcome, examples, resources, and sets of tests for evaluating the outcome. Methods can apply to a specific technology, such as HTML, or can be more generic where the advice applies no matter what technology, such as the methods supporting the Clear Language guideline.

    +

    Each outcome is associated with at least one method. Methods are informative and kept in how to documents. Each method contains techniques for meeting the outcome, examples, resources, and sets of tests for evaluating the outcome. Methods can apply to a specific technology, such as HTML, or can be more generic where the advice applies no matter what technology, such as the methods supporting the Clear Language guideline.

    Outcomes are written so that testers can determine the accessibility of technologies based solely on the outcome, even when methods do not yet exist for those technologies.

    -
    -

    Tests

    +

    Testing Outcomes

    What types of tests and scopes are used?

    WCAG 3.0 includes two (2) types of tests which are evaluated:

    @@ -277,28 +295,8 @@

    Tests

    -
    -

    This editor note needs to be rewritten to reflect the new proposals.

    -

    As we continue developing this content, we seek input on the following:

    -
      - -
    • How well does the testing approach defined here support additional requirements not addressed in 2.2?
      • -
    • How well does the testing approach defined here support regulatory needs?
      • -
    • How will these tests be integrated into a conformance model (including levels or scores)?
      • -
    • For multiple ways to measure, how will organizations declare which specification they are following in a way that is transparent, both to their users and for the purpose of verification in audits?
      • -
    • As written, outcomes and assertions are at the same level. Would moving assertions to the test level be more effective?
      • -
    -

    Next steps include:

    -
      -
    • Get feedback from designers, developers, and other communities on wording choice.
      • -
    • Finalize names and descriptions of scope and tests,
      • -
    • Develop detailed examples of methods and test,
      • -
    • Test the accuracy, reliability, repeatability, etc. of this approach,
      • -
    • Address all github issues under test types and terminology milestone.
      • -
    -
    -

    Types of tests

    +
    Types of tests

    WCAG 3.0 includes two (2) types of tests which are evaluated:

    • Quantifiable tests: Tests where there is a high degree of consistency between test results from different testers. Examples include testing whether certain properties exist in the content or if they match a value specified by the requirement.
      • @@ -311,7 +309,7 @@

      Types of tests

      Although content may satisfy all outcomes using quantifiable and qualitative tests, the content may not always be usable by people with a wide variety of disabilities. The assertions (see section 4.3 below) are designed to address this problem.

      -
      Quantifiable tests
      +
      Quantifiable tests

      Quantifiable tests rely on measuring properties of the content based on nominal values. The test results are objectively verifiable, to avoid variation of test results between different testers. Values are quantifiable, and could be boolean (true/false), for example to check the presence of titles, text alternatives, and accessible names. Other values could include numerical thresholds; for example, to check color luminosity ratios.

      Each method using quantifiable tests includes:

        @@ -320,7 +318,7 @@
        Quantifiable tests
      -
      Qualitative tests
      +
      Qualitative tests

      Qualitative tests rely on evaluating content based on a set of defined qualities and exceptions. The set of qualities and exceptions limit the scope of decisions, to minimize variation of test results arrived at by different testers. Still, some level of qualitative assessment is required, therefore the accuracy of the test results also depends on the knowledge and context of the testers to some degree.

      Each method using qualitative tests includes:

        @@ -337,7 +335,7 @@
        Qualitative tests
    -

    Test scopes

    +
    Test scopes

    Testing outcomes use items, views, user processes, and the aggregate to define what is being tested.

    Items are the smallest testable unit. They may be interactive components such as a drop down menu, a link, or a media player. They may also be units of content such as a word, a phrase, a label or error message, an icon, or an image.

    @@ -365,7 +363,7 @@

    Test scopes

    The aggregate is the combination of items, views, and user processes that collectively comprise the site, set of web pages, web app, etc.

    -

    Conditions

    +
    Conditions

    Some tests only apply in certain situations. Testing may occasionally require determining and referencing which specifications are being tested against. Methods will note whether a test always applies or under what conditions a test applies. Both Quantitative and Qualitative tests can be conditional.

    As we develop example outcomes and methods, we want to explore conditions overall and how multiple measurements fit in. We welcome comments on allowing alternative measurements to meet an outcome.

    @@ -383,6 +381,7 @@

    Conditions

    +

    Assertions and Procedures

    From 4ee95b64fdccd0ad49e3fe0942d13862a809f8ba Mon Sep 17 00:00:00 2001 From: rachaelbradley Date: Sat, 8 Apr 2023 15:12:15 -0400 Subject: [PATCH 08/18] Update index.html --- guidelines/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guidelines/index.html b/guidelines/index.html index 9923cd8c..b7d83bd3 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -471,7 +471,7 @@

    Testing Assertions

    -

    Conformance levels

    +

    Conformance Levels

    This section is exploratory. We are exploring several approaches to conformance. These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

    While there is a lot of overlap between WCAG 2 and WCAG 3, WCAG 3 will include additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

    From 4c77ec389946023b149cfd427ff608e0b55ee69a Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Mon, 17 Apr 2023 18:41:13 -0400 Subject: [PATCH 09/18] all editorial comments except GV's --- guidelines/index.html | 100 +++++++++++++++++++++--------------------- 1 file changed, 49 insertions(+), 51 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index b7d83bd3..a8ee924e 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -1,4 +1,4 @@ - + W3C Accessibility Guidelines (WCAG) 3.0 @@ -11,10 +11,10 @@
    -

    The W3C Accessibility Guidelines (WCAG) 3.0 provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. These guidelines address accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other web of things devices. They address various types of web content including static content, interactive content, visual and auditory media, and virtual and augmented reality. The guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

    +

    The W3C Accessibility Guidelines (WCAG) 3.0 provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of these. These guidelines address accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other web of things devices. The guidelines apply tNext steps include:o various types of web content including static, dynamic, interactive, and streaming content; visual and auditory media; virtual and augmented reality; and alternative access presentation and control. The guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

    Each guideline in this standard provides information on accessibility practices that address documented user needs of people with disabilities. Guidelines are supported by multiple outcomes to determine whether the need has been met. Guidelines are also supported by technology-specific methods to meet each outcome.

    This specification is expected to be updated regularly to keep pace with changing technology by updating and adding methods, outcomes, and guidelines to address new needs as technologies evolve. For entities that make formal claims of conformance to these guidelines, several levels of conformance are available to address the diverse nature of digital content and the type of testing that is performed.

    -

    See WCAG 3 Introduction for an introduction and links to WCAG technical and educational material.

    +

    See WCAG 3.0 Introduction for an introduction and links to WCAG technical and educational material.

    To comment, file an issue in the W3C silver GitHub repository. The Working Group requests that public comments be filed as new issues, one issue per discrete comment. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-agwg-comments@w3.org (comment archive). In-progress updates to the guidelines can be viewed in the public editors' draft.

    @@ -22,10 +22,10 @@

    Introduction

    -

    The current proposal for WCAG 3 is made up of different parts and sections, including:

    -
    • Two different directions for determining WCAG3 conformance. The feedback from our first few drafts was extensive. We have changed our approach to what is required to meet WCAG3.
      • +

      The current proposal for WCAG 3.0 is made up of different parts and sections, including:

      +
      • Two different directions for determining WCAG 3.0 conformance. The feedback from our first few drafts was extensive. We have changed our approach to what is required to meet WCAG 3.0.
      • We removed old material that was not consistent with the new approach. It does not mean we will not include it eventually, but to eliminate confusion, we have removed material that is no longer consistent with our current proposals.
        • -
      • WCAG3 Guideline placeholders which are short summaries of what we envision for the migration of the WCAG 2.x success criteria.
        • +
      • WCAG 3.0 Guideline placeholders which are short summaries of what we envision for the migration of the WCAG 2.x success criteria.

        • Content is in various states of maturity. The status is marked at the top of each section (see 1.2 Section status levels).

    @@ -35,9 +35,9 @@

    Introduction

    What’s new in WCAG 3.0?

    • WCAG 3.0 includes the needs of people with more types of disabilities.
      • -
    • We received a lot of feedback from our first drafts. We changed our approach to what is required to meet WCAG3.
      • +
    • We received a lot of feedback from our first drafts. We changed our approach to what is required to meet WCAG 3.0.
    • We removed old material that was not consistent with the new approach. It does not mean we will not include it eventually, but to eliminate confusion, we have removed material that is no longer consistent with our current proposals.
      • -
    • We are not publishing an updated WCAG3 Explainer.
      • +
    • We are not publishing an updated WCAG 3.0 Explainer.
    • There are high level summaries of what we think the guidelines will be.
    @@ -111,16 +111,16 @@

    Guidelines

    -

    The individuals and organizations that use WCAG vary widely and include web designers and developers, policy makers, purchasing agents, teachers, and students. In order to meet the varying needs of this audience, several layers of guidance are provided including functional categories of disabilities, general guidelines, outcomes that can be tested, a rich collection of methods, resource links, and code samples.

    +

    The individuals and organizations that use WCAG vary widely and include web designers and developers, policy makers, purchasing agents, teachers, and students. To meet the varying needs of this audience, several layers of guidance are provided including functional categories of disabilities, general guidelines, outcomes that can be tested, a rich collection of methods, resource links, and code samples.

    The following guidelines are being considered for inclusion in WCAG 3.0. They are used to illustrate what WCAG 3.0 could look like, demonstrate the structure, and test the process of writing and testing content. These guideline drafts should not be considered as final content of WCAG 3.0.

    -

    As more content is developed, this section will be a list of guidelines with a unique short name, and the text of the requirement written in plain language.

    +

    As more content is developed, this section will be a list of guidelines with a unique short name, and the text of the requirement written in plain language. The list is currently in alphabetical order, but we do not expect that to persist.

    Aid navigation

    -

    The site or app aids navigation

    +

    The website or app aids navigation

    Audio and video alternatives

    @@ -140,7 +140,7 @@

    Color and contrast

    Consistent design

    -

    The site or app has a consistent design

    +

    The website or app has a consistent design

    Content order

    @@ -172,11 +172,11 @@

    Harm from motion

    Keyboard support

    -

    The site or app supports the keyboard

    +

    The website or app supports the keyboard

    Mobile and pointer support

    -

    The site or app supports mobile and pointer inputs

    +

    The website or app supports mobile and pointer inputs

    Non-visual alternatives

    @@ -184,7 +184,7 @@

    Non-visual alternatives

    Prevent harm

    -

    The site or app does not cause harm

    +

    The website or app does not cause harm

    Process cognitive load

    @@ -192,7 +192,7 @@

    Process cognitive load

    Provide help

    -

    The site or app provides help

    +

    The website or app provides help

    Structured content

    @@ -204,7 +204,7 @@

    Text semantics

    Timing and interruptions

    -

    The site or app minimizes the impact of timing and interruptions

    +

    The website or app minimizes the impact of timing and interruptions

    User control

    @@ -219,7 +219,7 @@

    Conformance

    You might want to make a claim that your content or product meets the WCAG 3.0 outcomes. If it does meet the outcomes, we call this “conformance.” To conform to WCAG 3.0, your test results must show that your project is accessible.

    If you want to make a conformance claim, you must use the process described in this document. However, conformance claims are not required and your content can conform to WCAG 3.0, even if you don’t want to make a claim. You can still use this process to test your project’s accessibility.

    -

    WCAG 3.0 will include a new conformance model in order to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. There are several key goals for this new conformance model:

    +

    WCAG 3.0 will include a new conformance model to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. There are several key goals for this new conformance model:

    1. Develop a model that encourages websites to continue to improve accessibility (vs. stopping at the previous AA level);
      2. @@ -252,10 +252,10 @@

      Conformance

      Next steps include:

        -
      • Get feedback from designers, developers, and other communities on wording choice.
        • +
      • Get feedback from designers, developers, and other communities on wording choice,
      • Finalize names and descriptions of scope and tests,
        • -
      • Develop detailed examples of methods and test,
        • -
      • Test the accuracy, reliability, repeatability, etc. of this various models using these approaches,
        • +
      • Develop detailed examples of methods and tests,
        • +
      • Test the validity, reliability, sensitivity, adequacy, complexity and equity of the various models using these approaches,
      • Address all github issues under test types and terminology milestone.
    @@ -290,7 +290,7 @@

    Testing Outcomes

    • Item: A component or unit of content. Examples include a drop down menu, a media player, a phrase, or an image.
    • View: All content visually and programmatically available without a user-initiated substantive change.
      • -
    • User process: Series of user actions, and the distinct items and interactive views that support the actions, where each action is required in order to complete an activity.
      • +
    • User process: Series of user actions, and the distinct items and interactive views that support the actions, where each action is required to complete an activity.
    • Aggregate: Combination of all related items, user processes, and views.
    @@ -350,17 +350,17 @@
    Test scopes

    Views include all content visually and programmatically available without a substantive change. Conceptually, views correspond to the definition of a web page as used in WCAG 2.X, but are not restricted to content meeting that definition. For example, a view could be considered a "screen" in a mobile app or a layer of web content – such as a modal.

    -

    User processes are a series of user actions, and the distinct interactive views and items that support the actions, where each action is required in order to complete an activity. A user process may include a subset of items in a view or a group of views.

    +

    User processes are a series of user actions, and the distinct interactive views and items that support the actions, where each action is required to complete an activity. A user process may include a subset of items in a view or a group of views.

    Examples of a process include:

      -
    • Logging into a site and being recognized as an authenticated user;
      • +
    • Logging into a website and being recognized as an authenticated user;
    • Ordering an item, in which case the process includes the entire set of tasks from searching for the item, adding it to the shopping cart, paying for it, and receiving confirmation;
    • Submitting tax information, from start to end of the process; and
    • Interacting with other users in a virtual reality environment.

    A process is comprised of one or more views or subsets of views. Only the part of the views that support the user process are included in a test of the user process.

    -

    The aggregate is the combination of items, views, and user processes that collectively comprise the site, set of web pages, web app, etc.

    +

    The aggregate is the combination of items, views, and user processes that collectively comprise the website, set of web pages, web app, etc.

    Conditions
    @@ -411,16 +411,14 @@

    Assertions and Procedures

    Assertions

    -

    An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3, an assertion is an attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility. Testing of an assertion is always true/false — did they make an assertion and provide the required documentation?

    - -

    WCAG 3 recommends supporting documentation that an organization can use to improve or validate procedures and assertions. Conforming does not require this supporting documentation be made public.

    +

    An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3.0, an assertion is an attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility. Testing of an assertion is always true/false — did they make an assertion and provide the required documentation?

    Using Assertions

    Assertions may supplement methods in one or more outcomes. Assertions should only be used on outcomes and guidelines that allow assertions. Organizations can make an assertion that they followed a procedure to claim conformance.

    -

    Procedures used in assertions may be implemented at the organization level, during design and development, or during testing

    +

    Procedures used in assertions may be implemented at the organization level, during design and development, or during testing.

    Examples of procedures that may be used during implementation might include:

    • Training
      • @@ -434,18 +432,18 @@

      Using Assertions

    • Heuristic evaluation
    • Assistive technology testing
    -

    The AGWG is considering what will qualify as a procedure in WCAG 3. A procedure may be limited to guidance: +

    The AGWG is considering what will qualify as a procedure in WCAG 3.0. A procedure may be limited to guidance:

    • approved by AGWG and listed in WCAG,
    • that references publicly published guidance, or
    • that meets criteria specified in WCAG
    - or it may be any process that an organization uses to improve accessibility.

    + or it may be any process that an organization uses to improve accessibility. Comments or criticism of these alternatives is welcome.

    Documenting Assertions

    -

    Assertions must be documented as part of the conformance claim process. The required information may also be made available through the web site.

    +

    Assertions must be documented as part of the conformance claim process. The required information may also be made available through the website.

    Assertions might include the following information:

    • The statement being asserted
      • @@ -460,7 +458,7 @@

      Documenting Assertions

      Supporting Documentation for Assertions

      -

      WCAG recommends maintaining additional information that can support procedures. WCAG will not require organizations to provide supporting documentation to conform.

      +

      WCAG recommends maintaining additional information that an organization can use to improve or validate procedures and assertions. WCAG will not require organizations to provide supporting documentation to conform.

      The AGWG will add to this section as other areas are confirmed.

      @@ -474,7 +472,7 @@

      Testing Assertions

      Conformance Levels

      This section is exploratory. We are exploring several approaches to conformance. These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve them to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

      -

      While there is a lot of overlap between WCAG 2 and WCAG 3, WCAG 3 will include additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

      +

      While there is a lot of overlap between WCAG 2.X and WCAG 3.0, WCAG 3.0 will include additional tests and different scoring mechanics. As a result, WCAG 3.0 is not backwards compatible with WCAG 2.X.

      The percentages used are placeholders and will need to be determined through testing. As we continue developing this content, we seek input on the following: @@ -489,7 +487,7 @@

      Conformance Levels

      WCAG 3.0 defines three levels of conformance: bronze, silver, and gold. While it is easy to replicate the WCAG2 A, AA, AAA by renaming the levels, there is an opportunity to improve accessibility for people with disabilities by using a more advanced approach.

      -

      Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3.0. In order to reach Bronze level, the scope claimed in the conformance statement must pass a subset of Outcomes and Assertions. The subset will require enough Outcomes and Assertions to improve equity across functional needs.

      +

      Bronze is the minimum conformance level. Content that does not meet the requirements of the bronze level does not conform to WCAG 3.0. To reach Bronze level, the scope claimed in the conformance statement must pass a subset of Outcomes and Assertions. The subset will require enough Outcomes and Assertions to improve equity across functional needs.

      Silver level incentivizes organizations to go further to improve accessibility. One possibility that we are examining is that Silver level points can accumulate even prior to completing bronze but are not usable until Bronze is achieved. The goal is to encourage organizations to go beyond the minimum, especially where organizations want to be recognized for their efforts to go beyond minimum accessibility.

      @@ -538,8 +536,8 @@

      Adjectival Ratings

    Outcomes or Guidelines could be evaluated using adjectival ratings:

      -
    • This includes both directly Testable outcomes and Qualitative measures that are asserted.
      • -
    • Outcomes might be assigned an adjectival rating based on methods used to meet the outcome and issue severity
      • +
    • This includes both directly Quantifiable outcomes and Qualitative measures that are asserted.
      • +
    • Outcomes might be assigned an adjectival rating based on methods used to meet the outcome and issue severity.
    • Guidelines might be assigned an adjectival rating based on the outcomes and assertions completed under the guideline.
    @@ -578,20 +576,20 @@

    User generated content

  • uploaded photographs, or
  • uploaded videos or other multimedia.
    • -

    User Generated Content is provided for publication by visitors where the content platform specifically welcomes and encourages it. User-generated content is content that is submitted through a user interface designed specifically for members of the public and customers. Use of the same user interface as an authoring tool for publication of content by agents of the publisher (such as employees, contractors, or authorized volunteers) acting on behalf of the publisher does not make that content User Generated Content. The purpose of the User Generated Content Conformance is to allow WCAG 3 outcomes and methods to require additional or different steps to improve the accessibility of User Generated Content.

    -

    An important part of WCAG Conformance is the specific guidance that is associated with individual WCAG 3 guidelines and outcomes. Not all WCAG 3 guidelines will have unique outcomes and testing for User Generated Content. Unless User Generated Content requirements are specified in a particular guideline, that guideline applies as written whether or not the content is User Generated.

    +

    User Generated Content is provided for publication by visitors where the content platform specifically welcomes and encourages it. User-generated content is content that is submitted through a user interface designed specifically for members of the public and customers. Use of the same user interface as an authoring tool for publication of content by agents of the publisher (such as employees, contractors, or authorized volunteers) acting on behalf of the publisher does not make that content User Generated Content. The purpose of the User Generated Content Conformance is to allow WCAG 3.0 outcomes and methods to require additional or different steps to improve the accessibility of User Generated Content.

    +

    An important part of WCAG Conformance is the specific guidance that is associated with individual WCAG 3.0 guidelines and outcomes. Not all WCAG 3.0 guidelines will have unique outcomes and testing for User Generated Content. Unless User Generated Content requirements are specified in a particular guideline, that guideline applies as written whether or not the content is User Generated.

    We plan for a future Working Draft to include specific examples of guidelines with additional requirements for user generated content. One example would be 'alternative text'. The Authoring Tool Accessibility Guidelines (ATAG) has specific guidance for providing a mechanism for alternative text. The ATAG 2.0 Guideline B.2.3 - "Assist authors with managing alternative content for non-text content" could be adapted to provide specific, guideline-related guidance for user generated alternative text.

    The web content publisher should identify all locations of User Generated Content (such as commentary on hosted content, product descriptions for consumer to consumer for sale listings, and restaurant reviews) and perform standard accessibility evaluation analysis for each. If there are no accessibility issues, the User Generated Content is fully conforming.

    Steps to conform

    -

    If accessibility issues are identified, or if the website author wants to proactively address potential accessibility issues that might arise from User Generated Content, then all of the following must be indicated alongside the User Generated Content or in an Accessibility Statement published on the site or product that is linked from the view or page in a consistent location:

    +

    If accessibility issues are identified, or if the website author wants to proactively address potential accessibility issues that might arise from User Generated Content, then all of the following must be indicated alongside the User Generated Content or in an Accessibility Statement published on the website or product that is linked from the view or page in a consistent location:

    1. Clearly identify where User Generated Content can be found on the publisher's digital product (perhaps by id href);
    2. Clearly identify the steps taken to encourage accessibility in User Generated Content such as prompting the user for ALT text for their uploaded images before they are accepted and the disallowal of text attributes except as they are part of semantic markup such as strong, headings, etc., as enumerated in Guideline Outcomes;
    -

    Editor's Note: Once the conformance approach is included, content that passes all tests will be considered fully conformant. It remains to be determined how to address User Generated Content that has accessibility issues; and to define what minimum thresholds might be acceptable. We expect WCAG 3 to provide this guidance within individual guidelines and outcomes and to support testing for conformance. The working group is looking at alternative requirements to apply to User Generated Content guideline by guideline, and is seeking feedback on what would serve as reasonable requirements on how to best support accessibility in User Generated Content with known (or anticipated) accessibility issues. The working group intends to more thoroughly address the contents and the location of an accessibility statement in a future draft.

    +

    Editor's Note: Once the conformance approach is included, content that passes all tests will be considered fully conformant. It remains to be determined how to address User Generated Content that has accessibility issues; and to define what minimum thresholds might be acceptable. We expect WCAG 3.0 to provide this guidance within individual guidelines and outcomes and to support testing for conformance. The working group is looking at alternative requirements to apply to User Generated Content guideline by guideline, and is seeking feedback on what would serve as reasonable requirements on how to best support accessibility in User Generated Content with known (or anticipated) accessibility issues. The working group intends to more thoroughly address the contents and the location of an accessibility statement in a future draft.

    @@ -618,7 +616,7 @@

    Defining conformance scope

    Conformance requirements

    -

    In order for technology to conform to WCAG 3.0, the following conformance requirements apply:

    +

    For technology to conform to WCAG 3.0, the following conformance requirements apply:

    1. Conformance level - Content MUST meet the requirements of the selected conformance level.
    @@ -637,7 +635,7 @@

    Conformance claims

    Example conformance claim

    -

    On 12 August 2020, the following 10 views and 2 processes conform to WCAG 3.0 at a bronze level. Processes were selected because they are the most common activities on the site and include 4 unique views. The other 6 views are the most commonly used.

    +

    On 12 August 2020, the following 10 views and 2 processes conform to WCAG 3.0 at a bronze level. Processes were selected because they are the most common activities on the website and include 4 unique views. The other 6 views are the most commonly used.

    • Process 1: Order Newsletter (www.example.com, www.example.com/newsletter)
    • Process 2: Comment on Blog Post (www.example.com, www.example.com/blog, www.example.com/blog (with comment model open)
      • @@ -658,7 +656,7 @@

      Glossary

      Adequacy
      -

      Adequacy is subtle metric, but important to WCAG3 proposals. Adequacy describes if the formulas being used to process and score the accessibility testing results are using such a small interval that small changes in accessibility do not cause large changes in scoring. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +

      Adequacy is subtle metric, but important to WCAG 3.0 proposals. Adequacy describes if the formulas being used to process and score the accessibility testing results are using such a small interval that small changes in accessibility do not cause large changes in scoring. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      Adjectival Ratings

      A system to report evaluation results as a set of human-understandable adjectives.

      @@ -676,7 +674,7 @@

      Glossary

      Methods which are not required and meet a higher requirement than methods required to conform to Bronze.

      Complexity
      -

      Complexity refers to the resources required to accomplish the conformance testing. These could be crawler time, or time for human judgment testing. This would be a useful metric to have to answer the question of how much time WCAG3 takes to test as compared to WCAG 2.x. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +

      Complexity refers to the resources required to accomplish the conformance testing. These could be crawler time, or time for human judgment testing. This would be a useful metric to have to answer the question of how much time WCAG 3.0 takes to test as compared to WCAG 2.x. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      Conformance

      Satisfying all the requirements of the guidelines. Conformance is an important part of following @@ -689,7 +687,7 @@

      Glossary

      Equity
      -

      Equity is the outcome of processes and actions that ensure the spectrum of human reality obtains what is needed to participate, not solely access. As equity relates to WCAG it is about the impact the standards/guidelines have on people with disabilities, along with actually including PWD in the work. (This definition needs updating as the Equity group does more work. This definition came from the Equity subgroup of AGWG in Q2 2022)

      +

      Equity is the outcome of processes and actions that ensure the spectrum of human reality obtains what is needed to participate, not solely access. As equity relates to WCAG it is about the impact the standards/guidelines have on people with disabilities, along with actually including PWD in the work.

      This definition needs updating as the Equity group does more work. This definition came from the Equity subgroup of AGWG in Q2 2022

      Evaluation
      The process of examining content for conformance to these @@ -737,7 +735,7 @@

      Glossary

      See Outcomes.

      Process
      -

      A sequence of steps that need to be completed in order to accomplish an activity / task from +

      A sequence of steps that need to be completed to accomplish an activity / task from end-to-end.

      Reliability
      @@ -753,7 +751,7 @@

      Glossary

      Sensitivity
      -

      Sensitivity of a metric is related to the extent that changes in the output of the metric are quantitatively related to changes of the accessibility of the site being analyzed. This metric is useful for determining if the conformance proposal captures the impact of the severity of accessibility barriers on the final score and if different disabilities are treated equally by the proposal. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      +

      Sensitivity of a metric is related to the extent that changes in the output of the metric are quantitatively related to changes of the accessibility of the website being analyzed. This metric is useful for determining if the conformance proposal captures the impact of the severity of accessibility barriers on the final score and if different disabilities are treated equally by the proposal. Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

      Set of Tests
      @@ -776,7 +774,7 @@

      Glossary

      Validity
      -

      The extent to which the measurements obtained by a metric reflect the accessibility of the website to which it is applied. Does the rating that a web site or digital product achieve in any conformance proposal actually reflect the rating that it should get? Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011. Accessed on 29 July 2020

      +

      The extent to which the measurements obtained by a metric reflect the accessibility of the website to which it is applied. Does the rating that a website or digital product achieve in any conformance proposal actually reflect the rating that it should get? Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011. Accessed on 29 July 2020

    @@ -799,13 +797,13 @@

    Outcomes

    Methods map approximately to WCAG 2.X Techniques documents.

    -

    Approximate mapping of WCAG 2 and WCAG 3 documentation

    +

    Approximate mapping of WCAG 2 and WCAG 3.0 documentation

    - + From 00c9b480b5d98f358fcd2943c0192f73d8d84520 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Mon, 17 Apr 2023 19:01:44 -0400 Subject: [PATCH 10/18] GV comments GV6, GV3-5 hid the Normative section. --- guidelines/index.html | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index a8ee924e..5c7254c6 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -86,8 +86,7 @@

    Goals and Requirements

    While the majority of guidelines are still to be written and we continue to explore additional ways of validating conformance, we seek wider public review on the approach presented here.

    - -
    +
    @@ -219,15 +218,14 @@

    Conformance

    You might want to make a claim that your content or product meets the WCAG 3.0 outcomes. If it does meet the outcomes, we call this “conformance.” To conform to WCAG 3.0, your test results must show that your project is accessible.

    If you want to make a conformance claim, you must use the process described in this document. However, conformance claims are not required and your content can conform to WCAG 3.0, even if you don’t want to make a claim. You can still use this process to test your project’s accessibility.

    -

    WCAG 3.0 will include a new conformance model to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. There are several key goals for this new conformance model:

    - +

    WCAG 3.0 will include a new conformance model to address a wider range of user needs, test a wider range of technologies and support new approaches to testing. We are exploring several approaches to conformance. After studying the comments on the previous draft, these are the concepts that showed promise. We are giving an overview in this draft, but we continue to test the combination of the concepts.

    +

    There are several goals for this new conformance model:

    1. Develop a model that encourages websites to continue to improve accessibility (vs. stopping at the previous AA level);
    2. Better reflect the lived experience of people with disabilities, who successfully use sites that have some content that does not meet WCAG 2.0 AA, or who encounter barriers with sites that meet WCAG 2.0 AA;
    3. Allow for bugs and oversight by content authors, provided the impact of them upon users with disabilities is not substantial.
    -

    We are exploring several approaches to conformance. After studying the comments on the previous draft, these are the concepts that showed promise. We are giving an overview in this draft, but we continue to test the combination of the concepts.

    -

    These approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

    +

    The proposed approaches can fit together in a variety of ways. We will be testing these approaches and others for validity, reliability, sensitivity, adequacy, complexity and equity. We welcome suggestions on ways to improve these approaches to better meet these criteria and concerns about how they might affect accessibility. The working group plans to select from or even replace these options based on feedback, prototyping, and testing.

    There are two main approaches to evaluating accessibility that are promising. There are also detailed ideas that support these approaches. The two main approaches are:

    • Outcomes with Tests: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. Outcomes are addressed in Section 4.1. Tests are addressed in Section 4.1.1.
      • From e004d86a7c3210ff776227d4a16d452ab7ee523a Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 19 Apr 2023 20:22:35 -0400 Subject: [PATCH 11/18] added outcomes changed data-status to exploratory --- guidelines/index.html | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/guidelines/index.html b/guidelines/index.html index 5c7254c6..1ec8383e 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -153,9 +153,17 @@

      Control and focus appearance

      Control semantics

      Controls have correct semantic markup

    -
    +

    Error notification

    -

    Controls notify users when making mistakes

    +

    Inform users of errors and remedies

    +

    Outcome: Notifications provided: + Provides notification of an error so users know that an error has occurred.

    +

    Outcome: Notifications describe errors: + Provides a clear message describing the error so users understand the cause of the error.

    +

    Outcome: Instructions provided to remedy errors: + Provides instructions in response to an error so users know what steps to take to remedy the error.

    +

    Outcome: Timely and targeted guidance + Provides notification when the error occurs and identifies the source of error so users can readily refocus and remedy the error.

    Error prevention

    From 20ac51044b097af6ae710886d1293abae292fda3 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 11:26:49 -0400 Subject: [PATCH 12/18] created a new template folder for how-to --- how-tos/template-old/design.html | 28 +++++++++++++++++++++ how-tos/template-old/develop.html | 22 ++++++++++++++++ how-tos/template-old/examples.html | 20 +++++++++++++++ how-tos/template-old/get-started.html | 32 ++++++++++++++++++++++++ how-tos/template-old/index.html | 30 ++++++++++++++++++++++ how-tos/template-old/plan.html | 36 +++++++++++++++++++++++++++ how-tos/template-old/resources.html | 14 +++++++++++ 7 files changed, 182 insertions(+) create mode 100644 how-tos/template-old/design.html create mode 100644 how-tos/template-old/develop.html create mode 100644 how-tos/template-old/examples.html create mode 100644 how-tos/template-old/get-started.html create mode 100644 how-tos/template-old/index.html create mode 100644 how-tos/template-old/plan.html create mode 100644 how-tos/template-old/resources.html diff --git a/how-tos/template-old/design.html b/how-tos/template-old/design.html new file mode 100644 index 00000000..e78592c1 --- /dev/null +++ b/how-tos/template-old/design.html @@ -0,0 +1,28 @@ + + + + How-To - Design + + +
    +

    Design

    +
    +
    + +
    +

    Design responsibilities

    + {how it has to work or must do} +
    + +
    +

    Designer tips

    + {anything the designer should be aware of for this guideline} +
    + +
    +

    User testing and meaningful involvement

    + {involving people with disabilities for this guideline, user research with people with disabilities for this guideline} +
    +
    + + \ No newline at end of file diff --git a/how-tos/template-old/develop.html b/how-tos/template-old/develop.html new file mode 100644 index 00000000..cd4eb47f --- /dev/null +++ b/how-tos/template-old/develop.html @@ -0,0 +1,22 @@ + + + + How-To - Develop + + +
    +

    Develop

    +
    +
    +
    +

    Technical responsibilities

    + {high-level information about what developers should ensure content works or does} +
    + +
    +

    Technical tips

    + {anything a developer should watch out for or particularly be aware of} +
    +
    + + \ No newline at end of file diff --git a/how-tos/template-old/examples.html b/how-tos/template-old/examples.html new file mode 100644 index 00000000..f6e51443 --- /dev/null +++ b/how-tos/template-old/examples.html @@ -0,0 +1,20 @@ + + + + How-To - Examples + + +
    +

    Examples

    +
    +
    + + {examples should be rendered examples (inline or linked), either a single bullet list or multiple subsections as follows} + +
    +

    {Example Name}

    + {Use a copy of this section for each example if not using a bullet list of examples} +
    +
    + + \ No newline at end of file diff --git a/how-tos/template-old/get-started.html b/how-tos/template-old/get-started.html new file mode 100644 index 00000000..eecd9df9 --- /dev/null +++ b/how-tos/template-old/get-started.html @@ -0,0 +1,32 @@ + + + + How-To - Get Started + + +
    +

    Get Started

    +
    +
    +
    +

    Summary

    + {paragraph or bullet list of what is required} +
    + +
    +

    Why

    + {2-3 paragraph or bullet list of why the guideline is important} +
    + +
    +

    Who it helps

    + {paragraph or bullet list of the disability groups and barriers} +
    + +
    +

    How

    + {paragraph describing the generic cross-platform solution} +
    +
    + + \ No newline at end of file diff --git a/how-tos/template-old/index.html b/how-tos/template-old/index.html new file mode 100644 index 00000000..9cb51818 --- /dev/null +++ b/how-tos/template-old/index.html @@ -0,0 +1,30 @@ + + + + How-To + + +
    +

    {Guideline Name}

    +

    {Guideline}

    +
    +
    + + + +
    +
    +
    +

    Change Log

    + {list of non-editorial changes by date} +
    +
    + + \ No newline at end of file diff --git a/how-tos/template-old/plan.html b/how-tos/template-old/plan.html new file mode 100644 index 00000000..7f9928ad --- /dev/null +++ b/how-tos/template-old/plan.html @@ -0,0 +1,36 @@ + + + + How-To - Plan + + +
    +

    Plan

    +
    +
    +
    +

    Planning responsibilities

    + {what to ensure happens, and how it has to work or must do} +
    + +
    +

    Tips for collaboration

    + {Where communication is important with designers, developers, testers} +
    + +
    +

    Planning for each stage

    + +
    +

    How to get started early

    + {non-technical information about taking this guideline into account while developing site} +
    + +
    +

    How to remediate

    + {non-technical information about how to address this guideline in existing content} +
    +
    +
    + + \ No newline at end of file diff --git a/how-tos/template-old/resources.html b/how-tos/template-old/resources.html new file mode 100644 index 00000000..0635ac62 --- /dev/null +++ b/how-tos/template-old/resources.html @@ -0,0 +1,14 @@ + + + + How-To - Resources + + +
    +

    Resources

    +
    +
    + {links to style guides, videos} +
    + + \ No newline at end of file From cba1fdcf594eb27c9fb14655e09ba43f8f7f9338 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 15:37:31 -0400 Subject: [PATCH 13/18] template updates --- how-tos/template/index.html | 6 +-- how-tos/template/methods.html | 19 +++++++++ how-tos/template/userneeds.html | 41 +++++++++++++++++++ .../{design.html => z-design-old.html} | 0 .../{develop.html => z-develop-old.html} | 0 .../template/{plan.html => z-plan-old.html} | 0 6 files changed, 63 insertions(+), 3 deletions(-) create mode 100644 how-tos/template/methods.html create mode 100644 how-tos/template/userneeds.html rename how-tos/template/{design.html => z-design-old.html} (100%) rename how-tos/template/{develop.html => z-develop-old.html} (100%) rename how-tos/template/{plan.html => z-plan-old.html} (100%) diff --git a/how-tos/template/index.html b/how-tos/template/index.html index 9cb51818..f7b74364 100644 --- a/how-tos/template/index.html +++ b/how-tos/template/index.html @@ -13,11 +13,11 @@

    {Guideline Name}

    diff --git a/how-tos/template/methods.html b/how-tos/template/methods.html new file mode 100644 index 00000000..761ffb6d --- /dev/null +++ b/how-tos/template/methods.html @@ -0,0 +1,19 @@ + + + + How-To - Methods + + +
    +

    Methods

    +
    +
    +
    +

    {Outcome Name}

    +
      +
    1. {Method Name - Description}
      2. +
    +
    +
    + + \ No newline at end of file diff --git a/how-tos/template/userneeds.html b/how-tos/template/userneeds.html new file mode 100644 index 00000000..47818b65 --- /dev/null +++ b/how-tos/template/userneeds.html @@ -0,0 +1,41 @@ + + + + User Needs & Functional Needs + + +
    +

    User Needs & Functional Needs

    +
    +
    +

    +

    +

    Outcome1

    +
    +

    Barriers Encountered

    +
      +
      • +
    +
    +
    +

    Common User Needs

    +
      +
      • +
    +
    +
    +

    Unique User Needs

    +
      +
      • +
    +
    +
    +
    +

    Functional Needs

    +
      +
      • +
    +
    +
    + + \ No newline at end of file diff --git a/how-tos/template/design.html b/how-tos/template/z-design-old.html similarity index 100% rename from how-tos/template/design.html rename to how-tos/template/z-design-old.html diff --git a/how-tos/template/develop.html b/how-tos/template/z-develop-old.html similarity index 100% rename from how-tos/template/develop.html rename to how-tos/template/z-develop-old.html diff --git a/how-tos/template/plan.html b/how-tos/template/z-plan-old.html similarity index 100% rename from how-tos/template/plan.html rename to how-tos/template/z-plan-old.html From ccf7ac41c85b084799f8af15faee999edf4c7462 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 16:20:55 -0400 Subject: [PATCH 14/18] added user needs - minor update to template for user needs --- how-tos/error-notification/examples.html | 20 +++ how-tos/error-notification/get-started.html | 32 +++++ how-tos/error-notification/index.html | 30 ++++ how-tos/error-notification/methods.html | 19 +++ how-tos/error-notification/resources.html | 14 ++ how-tos/error-notification/userneeds.html | 146 ++++++++++++++++++++ how-tos/template/userneeds.html | 2 +- 7 files changed, 262 insertions(+), 1 deletion(-) create mode 100644 how-tos/error-notification/examples.html create mode 100644 how-tos/error-notification/get-started.html create mode 100644 how-tos/error-notification/index.html create mode 100644 how-tos/error-notification/methods.html create mode 100644 how-tos/error-notification/resources.html create mode 100644 how-tos/error-notification/userneeds.html diff --git a/how-tos/error-notification/examples.html b/how-tos/error-notification/examples.html new file mode 100644 index 00000000..f6e51443 --- /dev/null +++ b/how-tos/error-notification/examples.html @@ -0,0 +1,20 @@ + + + + How-To - Examples + + +
    +

    Examples

    +
    +
    + + {examples should be rendered examples (inline or linked), either a single bullet list or multiple subsections as follows} + +
    +

    {Example Name}

    + {Use a copy of this section for each example if not using a bullet list of examples} +
    +
    + + \ No newline at end of file diff --git a/how-tos/error-notification/get-started.html b/how-tos/error-notification/get-started.html new file mode 100644 index 00000000..eecd9df9 --- /dev/null +++ b/how-tos/error-notification/get-started.html @@ -0,0 +1,32 @@ + + + + How-To - Get Started + + +
    +

    Get Started

    +
    +
    +
    +

    Summary

    + {paragraph or bullet list of what is required} +
    + +
    +

    Why

    + {2-3 paragraph or bullet list of why the guideline is important} +
    + +
    +

    Who it helps

    + {paragraph or bullet list of the disability groups and barriers} +
    + +
    +

    How

    + {paragraph describing the generic cross-platform solution} +
    +
    + + \ No newline at end of file diff --git a/how-tos/error-notification/index.html b/how-tos/error-notification/index.html new file mode 100644 index 00000000..1a7e714d --- /dev/null +++ b/how-tos/error-notification/index.html @@ -0,0 +1,30 @@ + + + + How-To for Error Notification + + +
    +

    Error Notification

    +

    Inform users of errors and remedies.

    +
    +
    + + + +
    +
    +
    +

    Change Log

    + {list of non-editorial changes by date} +
    +
    + + \ No newline at end of file diff --git a/how-tos/error-notification/methods.html b/how-tos/error-notification/methods.html new file mode 100644 index 00000000..761ffb6d --- /dev/null +++ b/how-tos/error-notification/methods.html @@ -0,0 +1,19 @@ + + + + How-To - Methods + + +
    +

    Methods

    +
    +
    +
    +

    {Outcome Name}

    +
      +
    1. {Method Name - Description}
      2. +
    +
    +
    + + \ No newline at end of file diff --git a/how-tos/error-notification/resources.html b/how-tos/error-notification/resources.html new file mode 100644 index 00000000..0635ac62 --- /dev/null +++ b/how-tos/error-notification/resources.html @@ -0,0 +1,14 @@ + + + + How-To - Resources + + +
    +

    Resources

    +
    +
    + {links to style guides, videos} +
    + + \ No newline at end of file diff --git a/how-tos/error-notification/userneeds.html b/how-tos/error-notification/userneeds.html new file mode 100644 index 00000000..a7ed2d2f --- /dev/null +++ b/how-tos/error-notification/userneeds.html @@ -0,0 +1,146 @@ + + + + User Needs & Functional Needs + + +
    +

    User Needs & Functional Needs

    +
    +
    +

    +

    +

    Notifications provided - Provides notification of an error so users know that an error has occurred.

    +
    +

    Barriers Encountered

    +
      +
    • No error message
      • +
    • Error message that is not accessible to assistive technology (e.g., screen reader or reading assistance software)
      • +
    • Error message that is not visible (e.g., not in viewport)
      • +
    • Error message that is not identifiable (e.g., not recognizable as an error message)
      • +
    • Error message that is not legible (e.g., not distinguishable)
      • +
    +
    +
    +

    Common User Needs

    +
      +
    • Error message: User needs an error message when an error occurs so they know something went wrong.
      • +
    • Notification of changed values: User needs form to notify them when it changes values so they can review and verify accuracy of any changes to data.
      • +
    +
    +
    +

    Unique User Needs

    +
      +
    • Visual notification: User needs a visual notification so they know something went wrong.
      • +
    • Error message displays in viewport: User needs an error message that displays in the viewport so they can identify the error message and access the content with screen magnification.
      • +
    • High-contrast error message: User needs a prominent high-contrast error message so they can identify the error message.
      • +
    • Error message visually identifiable without symbols: User needs an error message that is identifiable without symbols so they can identify the error message.
      • +
    • Error message visually identifiable without text: User needs an error message that is identifiable without text so they can identify the error message.
      • +
    • Error message in consistent interface: User needs an error message with a consistent interface so they know they are interacting with the same digital product.
      • +
    +
    +
    +
    +
    +

    Notifications describe errors — Provides a clear message describing the error so users understand the cause of the error.

    +
    +

    Barriers Encountered

    +
      +
    • No description of cause of error
      • +
    • Unhelpful description of cause of error error
      • +
    • Error description that is not understandable (e.g., not clear)
      • +
    +
    +
    +

    Common User Needs

    +
      +
    • Error message describes the error: User needs an error message describing the error so they know what went wrong.
      • +
    +
    +
    +

    Unique User Needs

    +
      +
    • N/A
      • +
    +
    +
    +

    Instructions provided to remedy errors — Provides instructions in response to an error so users know what steps to take to remedy the error.

    +
    +

    Barriers Encountered

    +
      +
    • No remedy instructions
      • +
    • Unhelpful remedy instructions
      • +
    • Remedy instructions that are not understandable (e.g., not clear)
      • +
    +
    +
    +

    Common User Needs

    +
      +
    • Error message includes remedy instructions: User needs an error message describing the remedy so they know how to recover from the error.
      • +
    • Error message with remedy instructions displays at source of error: User needs an error message that displays at the source of the error so they can access the remedy instructions while focused on the source of the error.
      • +
    +
    +
    +

    Unique User Needs

    +
      +
    • Programmatically associated error message and source of error: User needs an error message that is programmatically associated with the source of the error so they can access the remedy instructions while focused on the source of the error.
      • +
    • Reassuring remedy instructions: User needs reassuring remedy instructions so they can have confidence they can resolve the error.
      • +
    +
    +
    +

    Timely and targeted guidance — Provides notification when the error occurs and identifies the source of error so users can readily refocus and remedy the error.

    +
    +

    Barriers Encountered

    +
      +
    • Error source is not visually identified
      • +
    • Error source is not programmatically identified
      • +
    • Error source is not programmatically associated with error message
      • +
    • Error source is not accessible to assistive technology
      • +
    • Error source indicator is not identifiable (e.g., not recognizable as an error source indicator)
      • +
    • Error source indicator is not legible (e.g., not distinguishable)
      • +
    • Error notification does not occur at time of error
      • +
    • Time-limited error notification limits access to instructions
      • +
    • Error source visual label is not the same as its programmatic label, making it difficult to move focus using speech
      • +
    • Error message doesn’t match source: Error message provides a different, ambiguous, or incomplete field label than the searchable visual label, making it difficult to search for the term in the form.
      • +
    +
    +
    +

    Common User Needs

    +
      +
    • Visual error source indicator: User needs a visual indicator of the error source so they know which component is the source of the error.
      • +
    • Error message provided when error occurs: User needs an error message that is provided when the error occurs so they can readily refocus on the source of the error.
      • +
    • Error message persists: User needs an error message that persists until the error is remedied so they can access the remedy instructions for as long as it takes to address the error.
      • +
    • Error message linked to error source: User needs an error message that is linked to the error source so they can readily move focus to invalid inputs to correct them.
      • +
    • Error message focused on reload: User needs an error message that is focused when the page reloads so they know there was an error
      • +
    +
    +
    +

    Unique User Needs

    +
      +
    • High-contrast error source indicator: User needs a prominent high-contrast error source indicator so they can identify the error source.
      • +
    +
    +
    +
    +
    +

    Functional Needs

    +
      +
    • Essential
      • +
    • Sensory - Vision and Visual
      • +
    • Sensory - Sensory Intersections
      • +
    • Cognitive - Attention
      • +
    • Cognitive - Language and Literacy
      • +
    • Cognitive - Learning
      • +
    • Cognitive - Memory
      • +
    • Cognitive - Executive
      • +
    • Cognitive - Mental Health
      • +
    • Cognitive - Cognitive and Sensory Intersections
      • +
    • Independence
      • +
    • Physical - Mobility
      • +
    • Physical - Motor
      • +
    • Physical & Sensory Intersections
      • +
    +
    + + + \ No newline at end of file diff --git a/how-tos/template/userneeds.html b/how-tos/template/userneeds.html index 47818b65..d9aad484 100644 --- a/how-tos/template/userneeds.html +++ b/how-tos/template/userneeds.html @@ -10,7 +10,7 @@

    User Needs & Functional Needs

    -

    Outcome1

    +

    {Outcome Name — Description}

    Barriers Encountered

      From 86880d25cd5f35164986fb9a3dbedf8649042ee7 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 17:35:54 -0400 Subject: [PATCH 15/18] Entered methods and minor updates to template --- how-tos/error-notification/index.html | 8 +- how-tos/error-notification/methods.html | 112 +++++++++++++++++++++++- how-tos/template/methods.html | 18 +++- 3 files changed, 128 insertions(+), 10 deletions(-) diff --git a/how-tos/error-notification/index.html b/how-tos/error-notification/index.html index 1a7e714d..222d098f 100644 --- a/how-tos/error-notification/index.html +++ b/how-tos/error-notification/index.html @@ -12,11 +12,11 @@

      Error Notification

    diff --git a/how-tos/error-notification/methods.html b/how-tos/error-notification/methods.html index 761ffb6d..da65a453 100644 --- a/how-tos/error-notification/methods.html +++ b/how-tos/error-notification/methods.html @@ -9,10 +9,118 @@

    Methods

    -

    {Outcome Name}

    +

    Notifications provided - Provides notification of an error so users know that an error has occurred.

    +
    +

    Method: What errors should be notified?

    +
      +
    • Notes: +
        +
      • Some errors do not require user intervention and correction of error. Users should not be interrupted for repetitive levels that don't require user action, such as a quick network connection drop. See the examples from What to do with repetitive errors of low severity?
        • +
      • If the system cannot move forward without user intervention, they should be notified.
        • +
      • If the system fails even if the user can’t fix it. If the app can’t do something, the user needs to be notified that something has gone wrong. If they can fix it, the user should be told how, and if they can’t, they should be told whatever is appropriate, even “try again in 30 minutes”
        • +
      • +
    • Tests: +
        +
      1. Identify when an error is made to make the judgement call of whether an error notification should exist (system errors as well as user errors) (see the list of user flows)
        2. +
      2. If an error is made, does an error notification exist?
        3. +
      • +
    +
    +
    +

    Method: Error messages need to be discernible, consistent, and accessible.

    +
      +
    • Tests: +
        +
      1. Can the user discern or detect the error notification? +
          +
        • Should not be off-screen or be a sound-only.
          • +
        • Is the notification semantic and meets other sections of WCAG3?
          • +
        • The notification should be consistent relative to the view, process or trigger so it is easier for a user to identify the source of the error and locate what location, window, or tab is producing the error.
          • +
        2. +
      • +
    +
    +
    +

    Method (Authoring Tool):UI frameworks produce discernible, consistent, and accessible error messages

    +
    +
    +

    Method: The technology stack supports notifications

    +
      +
    • User Agents: +
        +
      • When the page load fails, the browser handles server created errors through the headers. The server can provide a page to react or the browser react. The browser-provided-page needs to be understandable.
        • +
      • Browsers support <dialog> element so authors can style it appropriately.
        • +
      • Browsers can re-direct URL typos (or attacks) to common correct URLs (and inform the user when they do so.)
        • +
      • +
    • Assistive Technologies: +
        +
      • Assistive Technologies need to inform users that an error notification such as a modal window is opening.
        • +
      • Assistive Technologies need to support the <dialog> element
        • +
      • +
    • APIs. The spec is supported and implemented correctly. The API has to fire an event to notify the assistive technology that the event has occured. We need to enforce that all parts of the stack cooperate.
      • +
    • Note: These should not be separate methods but should be part of ARIA or Core Accessibility API, OR we have a built out example of how all the different parts fit together coherently to realize these outcomes
      • +
    +
    +
    +
    +

    Notifications describe errors — Provides a clear message describing the error so users understand the cause of the error.

    +
    +

    Method (all technologies): Explain the error in clear language

    +
      +
    • Notes: +
        +
      • Discussion of how to handle a situation where there is only one Method. We agreed that if there are multiple methods, we can articulate which combinations of methods are satisfactory to meet the outcome, or it can be one outcome, one method.
        • +
      • When creating outcomes, there is an ongoing question about when to break apart outcomes and when to combine related requirements. The advantage of breaking outcomes apart is that separate outcomes raise awareness of needs and ensure critical parts are not hidden at lower levels of documentation. The disadvantage of creating separate outcomes is the sheer number of resulting outcomes which may feel overwhelming. Groups should remain aware of this tension and document the rationale for breaking outcomes apart. Conversely, combining outcomes as “outcome A and outcome B” may result in outcome B being overlooked
        • +
      • +
    • Tests: +
        +
      1. Identify the type of error that has occurred
        2. +
      2. Identify where the error has occurred
        3. +
      3. The error message is written in clear language or has a link to a clear language explanation. “Error 10752” is a fail.
        4. +
      • +
    +
    +
    +
    +

    Instructions provided to remedy errors — Provides instructions in response to an error so users know what steps to take to remedy the error.

    +

    If it is known there is nothing the user can do, say so. (We should get input from ePub and XR.)

    +

    Methods:

      -
    1. {Method Name - Description}
      2. +
    2. A technology agnostic method of how to provide instructions (including from Http for server errors and Html for form submission errors). It is language and user flow driven rather than technology driven. Have illustrative examples for the different types, because making an exhaustive list would be extremely difficult to maintain. A heuristic tree (needs expert UX input): +
        +
      • An error occurred
        • +
      • Does this error require user action
        • +
      • (Zip code example) tell the user what they need to do
        • +
      3. +
    3. (user agent) use something like http error codes to prompt the user agent to give the appropriate instructions.
    +

    Notes:

    +
      +
    • Discussion on whether the instruction could be “server down” or “find someone sighted to help you with the form”. There was an idea of a rating from “Best available help” to “there is no human required to fix it”
      • +
    • It was brought up that the second part of the outcome “there is nothing the user can do” would ever apply, since the user might be able to do things like “try again tomorrow” or “contact customer support”
      • +
    • It was brought up that issues can range in “rating” from something simple like things that the user can fix themselves to things that would require contacting support and possibly escalation to someone with access/authorization to resolve the issue.
      • +
    +
    +
    +

    Timely and targeted guidance — Provides notification when the error occurs and identifies the source of error so users can readily refocus and remedy the error.

    +
    +

    Methods:

    +
      +
    • Technology neutral - it’s in relation to what the user is trying to do or read. When the error is detected needs to be balanced with interruptions. Timing is not essential success criteria also applies. There are a lot of things that can affect timing. It’s important that AT users actually get notified because if the page is not coded correctly, they may not receive the notification. The overall goal is to let the user know that an error occurred within an appropriate timeframe that makes sense and supports the user as best as possible.
      • +
    • Method for onblur client-side validation to give the user enough time to complete the input.
      • +
    • (Advanced?) method that gives a user the option to control the verbosity of the interruptions. Some users want to only be notified when they finish the form and not be interrupted while they are completed. Note that we don’t want to force a user to address the error which interrupts them from actually completing the task.
      • +
    +

    Notes:

    +
      +
    • What is timely for the type of error? E.g spelling error, vs. an error that requires a server verification like that a credit card number is authentic.
      • +
    • Is the user returned to the specific location of the error to correct it?
      • +
    • Is the inline error notification immediate (onblur) no later than when leaving the field?
      • +
    • Does “on submit” error notification walk the user through correcting the error?
      • +
    • Is the error notification removed when the error is corrected or the user is notified that the error has been corrected successfully?
      • +
    • Do we need a specific “keep the error notification visible until it is corrected?”
      • +
    • Development work should consider creating a decision tree of when in-line is the correct approach and when on-submit is the correct approach. There can be inline verification that goes to the server. How do we walk people through the process of deciding how to approach an error to give a consistent way to approach it. There are groupings that would help decide it.
      • +
    +
    diff --git a/how-tos/template/methods.html b/how-tos/template/methods.html index 761ffb6d..b53d0f4c 100644 --- a/how-tos/template/methods.html +++ b/how-tos/template/methods.html @@ -9,10 +9,20 @@

    Methods

    -

    {Outcome Name}

    -
      -
    1. {Method Name - Description}
      2. -
    +

    Outcome: {Outcome Name}

    +
    +

    Method: {Method Name - Description}

    +
      +
    • Notes: +
        +
        • +
      • +
    • Tests: +
        +
        2. +
      • +
    +
    From 9b9abbb8103df158926aee936a83d0ec5d375b7b Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 17:40:11 -0400 Subject: [PATCH 16/18] update guidelines to link to the How-To --- guidelines/index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/guidelines/index.html b/guidelines/index.html index 1ec8383e..c8683187 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -156,6 +156,7 @@

    Control semantics

    Error notification

    Inform users of errors and remedies

    +

    User needs and Methods by Outcome

    Outcome: Notifications provided: Provides notification of an error so users know that an error has occurred.

    Outcome: Notifications describe errors: From d8b9a488f8b514762edc7f9a2fb060b6f0a81139 Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 18:25:35 -0400 Subject: [PATCH 17/18] added ToC to Method list --- how-tos/error-notification/methods.html | 34 ++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/how-tos/error-notification/methods.html b/how-tos/error-notification/methods.html index da65a453..7b798524 100644 --- a/how-tos/error-notification/methods.html +++ b/how-tos/error-notification/methods.html @@ -8,8 +8,34 @@

    Methods

    +
    +

    Contents of this page:

    +
    -

    Notifications provided - Provides notification of an error so users know that an error has occurred.

    +

    Outcome: Notifications provided - Provides notification of an error so users know that an error has occurred.

    Method: What errors should be notified?

      @@ -63,7 +89,7 @@

      Method: The technology stack supports notifications

    -

    Notifications describe errors — Provides a clear message describing the error so users understand the cause of the error.

    +

    Outcome: Notifications describe errors — Provides a clear message describing the error so users understand the cause of the error.

    Method (all technologies): Explain the error in clear language

      @@ -82,7 +108,7 @@

      Method (all technologies): Explain the error in clear language

    -

    Instructions provided to remedy errors — Provides instructions in response to an error so users know what steps to take to remedy the error.

    +

    Outcome: Instructions provided to remedy errors — Provides instructions in response to an error so users know what steps to take to remedy the error.

    If it is known there is nothing the user can do, say so. (We should get input from ePub and XR.)

    Methods:

      @@ -102,7 +128,7 @@

      Instructions provided to remedy errors

    -

    Timely and targeted guidance — Provides notification when the error occurs and identifies the source of error so users can readily refocus and remedy the error.

    +

    Outcome: Timely and targeted guidance — Provides notification when the error occurs and identifies the source of error so users can readily refocus and remedy the error.

    Methods:

      From 4ad0f6bb63dc837313046fdc974a43f57aa544ef Mon Sep 17 00:00:00 2001 From: Jeanne Spellman Date: Wed, 24 May 2023 18:27:25 -0400 Subject: [PATCH 18/18] fix link to How-To --- guidelines/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guidelines/index.html b/guidelines/index.html index c8683187..00358aa5 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -156,7 +156,7 @@

      Control semantics

      Error notification

      Inform users of errors and remedies

      -

      User needs and Methods by Outcome +

      User needs and Methods by Outcome

      Outcome: Notifications provided: Provides notification of an error so users know that an error has occurred.

      Outcome: Notifications describe errors:

    WCAG 2 WCAG 3 WCAG 3.0
    Success Criteria