From 8776de398d98dfcfe5940699d92f0ecef4aa49ac Mon Sep 17 00:00:00 2001 From: Ross Mullen <43454021+rossmullen@users.noreply.github.com> Date: Fri, 13 Aug 2021 22:28:39 +1000 Subject: [PATCH 1/3] Create STANDARDISED-ACCESSIBILITY-TESTING.md --- .../STANDARDISED-ACCESSIBILITY-TESTING.md | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md diff --git a/RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md b/RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md new file mode 100644 index 0000000..415f0a0 --- /dev/null +++ b/RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md @@ -0,0 +1,38 @@ +--- +Status: `Proposal` # Please do not change this. +Implementer: # It will be changed upon merging and as it moves through the RFC stages +--- + +# Standardised manual accessibility testing + +## The issue to be solved + +Web accessibility is too subjective. Reading the WCAG success criteria is challenging and trying to agree on what constitutes a failure is hard, multiple people may have multiple views each slightly different. Normative failings (things which must pass) in WCAG becomes conflated with accessibility best practice and what people *feel* is poor accessibility. Agreeing on what constitutes a failure is the first step towards testing in a consistent way and having consistent results. + +Manual accessibility testing is aimed at conveying facts. Tests should strive to avoid personal preferences for identifying accessibility failures. + +This article forms the approach +https://www.tpgi.com/heading-off-confusion-when-do-headings-fail-wcag/ +> WCAG techniques, such as H42: Using h1-h6 to identify headings and ARIA12: Using role=heading to identify headings, recommend that heading markup indicate the appropriate heading level for the content, but they don’t go so far as to define what’s “appropriate”—an issue that has been the subject of considerable discussion. **So although hierarchical heading structures reflect a best practice, skipping heading levels does not represent a WCAG failure.** + +## A short description of the desired outcome or solution + +The outcome is a community driven master list of all 50 WCAG 2.1 AA success criteria expanded out into simple easy to understand individual tests. A developer building a component would use the same tests from the same list as a accessibility specialist, accessibility tester, BA or anyone else involved in the accessibility. The tests remove the personal opinions of what people believe is an accessibility failure but isn't and makes it simpler to apply the minimum level of accessibility consistently. + +The master list would invite community input but not every request would be actioned. Requests undergo a rigorous review and require justification that _a). it is a failure_ or _b). the test requires more detail_. + +## Technical details + +* 103 separate accessibility tests comprising all 50 WCAG 2.1 AA success criteria, as an example https://canaxess.github.io/accessibility-resources/ +* filterable by role or component +* excel export functionality + + From 6f02430c238c4877743bffce795bf3231854c9f3 Mon Sep 17 00:00:00 2001 From: Ross Mullen Date: Thu, 19 Aug 2021 18:11:05 -0700 Subject: [PATCH 2/3] updates --- ...TING.md => standardised-accessibility-testing.md} | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) rename RFC-by-stage/1-approved/{STANDARDISED-ACCESSIBILITY-TESTING.md => standardised-accessibility-testing.md} (92%) diff --git a/RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md b/RFC-by-stage/1-approved/standardised-accessibility-testing.md similarity index 92% rename from RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md rename to RFC-by-stage/1-approved/standardised-accessibility-testing.md index 415f0a0..cf76901 100644 --- a/RFC-by-stage/1-approved/STANDARDISED-ACCESSIBILITY-TESTING.md +++ b/RFC-by-stage/1-approved/standardised-accessibility-testing.md @@ -26,13 +26,5 @@ The master list would invite community input but not every request would be acti * 103 separate accessibility tests comprising all 50 WCAG 2.1 AA success criteria, as an example https://canaxess.github.io/accessibility-resources/ * filterable by role or component * excel export functionality - - +* working from a common language of agreeing what is a failure/pass according to WCAG +* making it easy for devs, ui, ux and whoever else to interrogate and understand \ No newline at end of file From 168ab653585922cd4627bf28bf1b89ea705c5f2a Mon Sep 17 00:00:00 2001 From: Elise Chant Date: Tue, 28 Sep 2021 08:46:09 +1000 Subject: [PATCH 3/3] format --- .../standardised-accessibility-testing.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/RFC-by-stage/1-approved/standardised-accessibility-testing.md b/RFC-by-stage/1-approved/standardised-accessibility-testing.md index cf76901..3e2749d 100644 --- a/RFC-by-stage/1-approved/standardised-accessibility-testing.md +++ b/RFC-by-stage/1-approved/standardised-accessibility-testing.md @@ -7,24 +7,25 @@ Implementer: # It will be changed upon merging and as it moves through the RFC s ## The issue to be solved -Web accessibility is too subjective. Reading the WCAG success criteria is challenging and trying to agree on what constitutes a failure is hard, multiple people may have multiple views each slightly different. Normative failings (things which must pass) in WCAG becomes conflated with accessibility best practice and what people *feel* is poor accessibility. Agreeing on what constitutes a failure is the first step towards testing in a consistent way and having consistent results. +Web accessibility is too subjective. Reading the WCAG success criteria is challenging and trying to agree on what constitutes a failure is hard, multiple people may have multiple views each slightly different. Normative failings (things which must pass) in WCAG becomes conflated with accessibility best practice and what people _feel_ is poor accessibility. Agreeing on what constitutes a failure is the first step towards testing in a consistent way and having consistent results. Manual accessibility testing is aimed at conveying facts. Tests should strive to avoid personal preferences for identifying accessibility failures. This article forms the approach https://www.tpgi.com/heading-off-confusion-when-do-headings-fail-wcag/ + > WCAG techniques, such as H42: Using h1-h6 to identify headings and ARIA12: Using role=heading to identify headings, recommend that heading markup indicate the appropriate heading level for the content, but they don’t go so far as to define what’s “appropriate”—an issue that has been the subject of considerable discussion. **So although hierarchical heading structures reflect a best practice, skipping heading levels does not represent a WCAG failure.** ## A short description of the desired outcome or solution -The outcome is a community driven master list of all 50 WCAG 2.1 AA success criteria expanded out into simple easy to understand individual tests. A developer building a component would use the same tests from the same list as a accessibility specialist, accessibility tester, BA or anyone else involved in the accessibility. The tests remove the personal opinions of what people believe is an accessibility failure but isn't and makes it simpler to apply the minimum level of accessibility consistently. +The outcome is a community driven master list of all 50 WCAG 2.1 AA success criteria expanded out into simple easy to understand individual tests. A developer building a component would use the same tests from the same list as a accessibility specialist, accessibility tester, BA or anyone else involved in the accessibility. The tests remove the personal opinions of what people believe is an accessibility failure but isn't and makes it simpler to apply the minimum level of accessibility consistently. The master list would invite community input but not every request would be actioned. Requests undergo a rigorous review and require justification that _a). it is a failure_ or _b). the test requires more detail_. ## Technical details -* 103 separate accessibility tests comprising all 50 WCAG 2.1 AA success criteria, as an example https://canaxess.github.io/accessibility-resources/ -* filterable by role or component -* excel export functionality -* working from a common language of agreeing what is a failure/pass according to WCAG -* making it easy for devs, ui, ux and whoever else to interrogate and understand \ No newline at end of file +- 103 separate accessibility tests comprising all 50 WCAG 2.1 AA success criteria, as an example https://canaxess.github.io/accessibility-resources/ +- filterable by role or component +- excel export functionality +- working from a common language of agreeing what is a failure/pass according to WCAG +- making it easy for devs, ui, ux and whoever else to interrogate and understand