Accessibility supported Subgroup

TPAC 2022 presentation - 13 September 2022

About “Accessibility supported Subgroup”

Members:

• Makoto Ueki (facilitator)
• Laura Miller
• Bruce Bailey
• Andrew Kirkpatrick
• Poornima Badhan Subramanian

For more information: Subgroup Wiki

• Meeting minutes are available.

Core Questions

• How did the concept of "Accessibility Supported" work in different countries/regions and/or organizations?

​

• Should we keep/modify the concept in WCAG 3?

​

Our Goals

• Document use cases of the "Accessibility Supported".
• Present pros and cons on both:

1) Keep "Accessibility Supported" and

2) NOT keeping "Accessibility Supported" for WCAG 3.

​

2 Steps towards Our Goals

STEP 1. Document use cases

​

STEP 2. Pros and Cons “Keep” vs “Remove” for WCAG 3

What is “Accessibility supported”?

“5.2 Conformance Requirements” in WCAG 2.1

​

5.2.4 Only Accessibility-Supported Ways of Using Technologies

​

Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported. (See Understanding accessibility support.)

How it was defined in WCAG 2

​

“6. Glossary” in WCAG 2.1

​

accessibility supported

​

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

​

Historical Notes from Gregg

We did not specify the exact number or which AT and which browsers because they kept changing. The intent was that a later document would be created that could be used as guidance. This never happened. The best we came up with in discussion was “the top 4 free browsers” and “the major AT in each category. There was a concern that the top AT were not affordable by all. .......

​

See more at the bottom of “6. Glossary” section of our document

STEP 1. Use Cases

In no particular order (* We’ll change the order) :

1. Japan (one other language than English)
2. Section 508 (one government)
3. Organization (one company)
4. Accessibility Overlays
5. PDF (Non W3C technology vendor)
6. W3C (unapproved prototype of database)

Question

Is the “Accessibility Overlay” an assistive technology?

Example 1: Use Case in Japan

​

“Accessibility supported” has been essential for Japan

• In 2010, JIS (National standard) adopted WCAG 2 SCs as they are.
• Big difference was the functional level of screen readers.
• More than 80% screen reader users in Japan are using PC-Talker.
• It is only available for Japanese language, made by Japanese AT vendor.
• The support for HTML/ARIA is less than JAWS/NVDA.

Example 1: Use Case in Japan

​

A sufficient technique to meet SC 2.4.1 Bypass Block

• G1: Adding a link at the top of each page that goes directly to the main content area
• “Skip link” was required to use rather than HTML headings markup at first.
• PC-Talker hadn’t provided “Heading navigation” yet (around 2010).
• After some years later, it started implementing “Heading navigation”.
• It allowed us to rely on h1-h6 markup to meet SC 2.4.1 since then.

.

Example 1: Use Case in Japan

​

Concept of “Accessibility supported” has been essential in Japan

• Allows WCAG to be internationally adoptable guidelines.
• Allows global companies to adopt the same guidelines (WCAG = ISO/IEC = JIS)

Obviously the efforts requires huge challenges

• Human resources to develop a test suite and test with UAs/ATs
• Both test suites and testing results must be maintained
• Accessibility supported information for Japanese content (only in Japanese)

​

Example 2: Adobe PDF

​

Concept of “Accessibility supported” benefits non-W3C technologies

• Allows WCAG to be compatible with any digital technologies.
• Allows technology vendors to document sufficient techniques
• Allows AT vendors to figure out how their products can support techniques
• Makes it possible for technology vendors and AT vendors to work together

Example 3: W3C’s database

​

[Unapproved Prototype] Accessibility Support Database

• Provides a test suite based on sufficient techniques for WCAG 2.
• It could make translations into different languages possible.
• Shares the testing results with different UAs (including ATs)
• It is possible for anyone to include any ATs in different languages.

​

Unfortunately the database was “unapproved” due to scalability issues.

​

STEP 2. Pros and Cons

See the full table

Question

Which Direction Should We Go?

​

1. Keep “accessibility-supported” (AS) concept

OR

• Remove AS.

​

​

If “Keep”, Which Option Should We Take?

• As-is (i.e., without test files and testing results).
• Some Methods can be non-accessibility-supported for some languages/ATs.
• Develop a database (including test files and testing results).
• Something like “Accessibility Support Database”
• Develop test files at least (without testing results).
• People can translate them into their languages and do testing with any ATs they want.
• Keep it limited to documented Methods (without test files and testing results).
• We don’t document Methods ourselves that are not accessibility supported.
• Promote AS issues in each Guideline in WCAG 3 as well as supporting documents (without test files and testing results).

​

​

Which Direction Should We Go?

• Keep “accessibility-supported” (AS) concept

​

​

​

​

• Remove AS.

​

​

WCAG 3では、例えば...

• PCならNVDA、スマホならVoiceOverが無償で利用可能なので、この2つを

「ベースライン」にすれば、日本語圏特有のテストはしなくてもよくなる？？

• ただ、新しい技術や仕様のサポート状況の確認はグローバルで必要

​

• それとも、従来通り、PC-Talkerなど様々なスクリーンリーダー等のサポート

　　状況も把握するために、テストファイル作成＆検証作業が不可欠？？

• W3C（AGWG）に何か要望はある？