Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wcag22inbrief eow #3252

Merged
merged 16 commits into from Jul 28, 2023
Merged

Wcag22inbrief eow #3252

merged 16 commits into from Jul 28, 2023

Conversation

mbgower
Copy link
Contributor

@mbgower mbgower commented Jun 26, 2023

@mbgower mbgower marked this pull request as ready for review June 30, 2023 14:39
@mbgower
Copy link
Contributor Author

mbgower commented Jul 18, 2023

Received the following comments from @gundulaniemann in survey. I am going to respond here for posterity:

accessible authentication:
I am confused as to what is restricted with which accessible authentication level.
The what to do
"Don’t make people recognize objects or recall personal information to login"
and
"Don’t make people solve, memorize, or transcribe something to log in."
to me basically means the same. Rather the second restricts more, yet it was cited from the 'minimum' version.

You aren't alone in your observation that the SCs are cumulative but ALSO redundant. It make a challenge providing a succinct summary that stands alone. The WG previously voted not to restate the earlier requirement as part of the enhanced 'in brief'. I've nonetheless tried to add a tiny bit of connecting text, which has been reworded. Please review to see if it's any better.

Dragging Movements:
The SC is about mouse and touch, and the point is that the user cannot perform a reliable and exact dragging movement. This should be reflected int he Why it's important section.
Suggestion:
Some people cannot perform an exact dragging movement.

The EO folks are interested in focusing on inability as opposed to difficulty, hence "Some people cannot use a mouse to drag items". As well, although you are correct that touchscreens are relevant, the use of "mouse" was felt to be more immediately recognizable than "pointer", which is nonetheless used in the what to do section -- so 'mouse' provides a recognizable synonym.

Focus not obscured enhanced:
The point is not, what people do not use nor whether they would be able to use a mouse, but what users in fact chose to use.
Why it's important: People who use a keyboard need to easily see what has keyboard focus.

focus not obscured minimum:
The point is not, what people do not use nor whether they would be able to use a mouse, but what users in fact chose to use.
Why it's important: People who use a keyboard need to see what has keyboard focus.

Getting back to the EO perspective, many people not as familiar with accessibility will more quickly understand 'oh, it's for people who can't use a mouse'. The keyboard is obviously present in the same sentence and in the prior line. And of course the Understanding document provides in depth infor on the needs of those reliant on the keyboard API. This wording also gets us away from saying "keyboard" twice in one brief line!

redundant entry:
not sure about the grammar as I not a native speaker.
Some people with cognitive disabilities have difficulty to remember what they entered before.

Corrected

target size minimum:
I prefer "cannot" instead of "find it hard to".

Adopted.

@alastc alastc merged commit 33d4e1a into main Jul 28, 2023
1 check passed
@alastc alastc deleted the wcag22inbriefEOW branch July 28, 2023 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants