in brief material for WCAG 2.0 success criteria

[mbgower]

Brief descriptions for all WCAG 2.0 A and AA requirements. A continuation of the work begun in #3191 and #2905 to address #744

I set as a goal to limit each line to 10 words or fewer
For the benefits, I tried to reuse the same phrases where possible. I've documented the phrases used and some explanation in the following document
Key beneficiaries language.docx

[gundulaniemann]

I understand that larger feedback should be given in github instead of in the questionnaire.
If there is a better way than a comment, I am happy to learn.

Here are my remarks on the current version:

Understanding Contrast (Minimum)
there are various vision impairments where users rely on good contrast.
what about:

Key beneficiaries

Users with vision impairments

I'd also agree to "Users with reduced vision"

Understanding Error Prevention (Legal, Financial, Data)
I do not see the impact on users with reduced hearing.
Can you explain?

Understanding Info and Relationships
As the information should be programmatically determined, I suggest to add blind users to the list of beneficiaries.

Understanding Keyboard
What about a positive wording like
"Enable accomplishment by keyboard for all user actions."?

Understanding Language of Page
in fact it is about the language being programmaticaly determined, so for example screen readers pronounce understandably.
The user cannot even see the indication.
Suggestion:

Objective

Assistive technology can identify the language of a page

Author task

Indicate the predominant language on a page through technology

Key beneficiaries

blind users and others reliant on speech output/dd>

Understanding Language of Parts
similar as for language of page
Suggestion:

Objective

Assistive technology can identify the languages used within a page<

Author task

Indicate when words are in a different language through technology

Key beneficiaries

blind users and others reliant on speech output/dd>

Understanding Non-text Content
I understand from the SC that the text alternative might be available only to assistive technology.
As a consequence, only users using assistive technology benefit.
Suggestion:
Benefeciaries: Users using assistive technology

Understanding Resize Text
Users with various vision impairments benefit from text enlargement. Also, low vision is a legal term in several countries, and most users benefiting from text enlargement without magnifying tool do not fall into the legal category.
Suggestion:
Beneficiaries: Users with reduced vision.

Understanding Use of Color
users benefiting most are color-blind users.
Only some of them might be low vision as well (in the legal sense).
Blind users do not benefit from visuals (unless they see but are legally blind).
Suggestion:
Color-blind users and those with reduced sight

[mbgower]

Thanks @gundulaniemann
FYI, the better way to do this, if you are able, is to switch from the Conversation to the 'Files changed' view and click on the blue + symbol icon that appears at the line number (on hover or focus), as shown in this small screen snippet

This lets you put in comments directly on a file. Once in this mode, you can also activate the Add a suggestion button (Cmd+G) and directly enter new wording for that line.

This lets me put in responses directly into the file. Another benefit of following that procedure I describe is that it also appears in the Conversation thread. Unfortunately, only putting your comments in the Conversation view doesn't also get captured in the File view.

Following this procedure should also result in less typing for you, since you never need to say what file (or line) you're talking about. It's all baked in.

FYI, I've added in each of your comments, and then addressed and resolved them.

[mgifford]

Is this needed? The AT needs to interpret the components properly so that the author's intent is conveyed to the user. However, when are people using AT ever required to even understand what a component is.

[mbgower]

@mgifford
It could come down to finding a better word than 'understand', but consider this scenario:

1. when the author assigns the correct role, the AT identifies it as, say, a menu, and the user thinks "okay, I'm in a menu" She understands what the interaction is (and some ATs will tell her basic interaction keys).
2. when the author assigns a name, the AT identifies it, and if the user is reliant on the AT presentation, she may think "Okay, this is the View menu, that's not the menu I want, so I'll proceed to the next one"
3. when the author assigns the value or state, as the user advances, she hears 'View menu, closed', moves on to the Profile menu and might hear which profile is currently selected.

That's the intended outcome of 4.1.2, so arguably, the goal is about the user getting the information. This differs a bit from 4.1.1 Parsing, where it really is just about making sure the AT is able to understand/process the code, even if there's no discernible impact on the users these days (and the reason there's no real user benefit/effect is why 4.1.1 is being 'dropped').

[alastc]

Hi @mbgower, I was trying to merge, but there are some conflicts with the WCAG 2.2 understanding docs.

Given that we'll need to merge this into the WCAG 2.1 branch as well, could you remove the updates to the 2.2 docs please?

[mbgower]

@alastc as per email, I believe this has been resolved. Please LMK is you are still finding a conflict

I think these have been incorporated