W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2022

Re: SURVEY: WCAG 2.2 editorial updates

From: Alastair Campbell <acampbell@nomensa.com>
Date: Fri, 19 Aug 2022 17:20:21 +0000
To: Jonathan Avila <jon.avila@levelaccess.com>, "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
Message-ID: <PR3PR09MB5347838E29A4124A5D69B290B96C9@PR3PR09MB5347.eurprd09.prod.outlook.com>
Hi everyone,

This is a status update on the various issues/updates going on. First the ones in survey:

Focus appearance survey Q 3<https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates/#wbsq9>.
Adding a paragraph for 'visual presentation' Pt2

The proposal has been updated to:
“What is perceived as the user interface component and any sub-components (to determine enclosure or size) depends on its visual presentation. The visual presentation includes, but is not limited to the component’s visible content, border, component-specific background, and effects emanating from the visible component such as shadows or glow effects.”

Focus appearance survey Q4.<https://www.w3.org/2002/09/wbs/35422/focus-appearance-updates/#wbsq7>
4. Making sub-components require focus indicators

The proposal removes the paragraph on sub-components, but adds “or sub-component” to the bullets. The effect is to require the focus-indicator to be on the sub-component rather than it being the authors choice. (You could still maintain an indicator on the parent component, that is not impacted.)

As we’ve looked at examples for this, the only complication was where focus & selection overlap. The browser-native controls don’t do this very well (but are exempted), the custom versions have more options because you can use more space and methods (e.g. borders, icons, backgrounds etc).

In the small meeting today there was support for this approach, it is in the survey. The understanding doc will need an update.

Then for the miscellaneous issues:

Target size - Problems with the Equivalent exception #2569

From the email discussion, I propose that we align the bullets to match the AAA version, implemented here:

To close issue #2569, the equivalent exception is: “The function can be achieved through a different control on the same page that meets this criterion.”

Clarify Accessible Authentication by including "remembering user names and passwords" in the SC text #2577

There was some disagreement that everything covered by cognitive function test was really a “test”. After exploring some options there doesn’t appear to be a better one, and the current form is tolerable, so PR 2609<https://github.com/w3c/wcag/pull/2609/files> seems good.

Improvement for Dragging Movement definition note #2595

There was conversation about whether to include a slider example as it overlaps with pointer-gestures a lot.
I’m still leaning towards keeping the examples simple:
“Examples of draggable elements include list items, text elements, and images.”

Clarification for Consistent Help, 2nd Note #2596

There have been some improvements to the text for #2605<https://github.com/w3c/wcag/pull/2605/files>, so the note reads:
“For this Success Criterion, the same relative order can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). [UPDATED:] The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).”

Accessible authentication to follow…

Received on Friday, 19 August 2022 17:21:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 19 August 2022 17:21:14 UTC