- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 27 Apr 2022 11:32:46 -0400
- To: Alastair Campbell <acampbell@nomensa.com>
- Cc: Sarah Horton <sarah.horton@gmail.com>, Gregg Vanderheiden <gregg@raisingthefloor.org>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Thanks Alastair. About Visual cue or visual indicator: Borrowing from a previous comment, it has to be "in a way that’s appropriate for the context and current conventions". I do not think examples for visual cue in all contexts can be provided exhaustively and as conventions evolve / change over time. It will be akin to listing "input purposes" for SC 1.3.5 and yet remain incomplete. The proposed visible focus indicator SC will surely address cues and hints to become visually discernible when presented in the UI suitably when needed. By convention links used to be underlined and blue but now there are other ways for distinguishing them. Without dropdown or expand/collapse feature, an arrow next to an element will make no sense. Now the presence of that arrow indicates that. Can informative guidance be enhanced for one or more existing SC to cover this? Sure it will not be normative but will educate designers and developers. Thanks and best wishes, Sailesh On 4/27/22, Alastair Campbell <acampbell@nomensa.com> wrote: > Hi Sailesh, > > The question we are struggling to answer, at least in a WCAG 2.x framework, > is: What constitutes a visual cue? > > I’m afraid placement of the guideline is a secondary consideration because > if we can’t answer that, we’ll have to defer the SC. > > Kind regards, > > -Alastair > > > From: Sailesh Panchang > Alastair, > The question I have is why is this requirement not being considered > under Principle 1: Perceivable > The description on the "Understanding" page suggests all the groups > listed there are unable to perceive the controls. > This is not different from a piece of text that is really a link but > has no underline or other visual distinctive trait to convey that the > element is an operable element. > Depending on the context and functionality, if the controls get > exposed in a logical order, or by the presence of a visual cue (and > role/state etc.) the user is informed that user action is needed to > access child / related controls, the content will be accessible. > That is what is covered by "Making Content Usable for People with > Cognitive and Learning Disabilities" > Is this not already covered by WCAG 2.0 SCs? > The Understanding doc for proposed SC 3.2.7 states: "Some design > approaches hide controls and require certain user interactions, such > as mouseover, to reveal them (both visually and programmatically)". > My take: Unless the design includes a visual cue , even an individual > without any disability whatsoever will not be able to figure out that > the element needs to be operated upon via mouseover or such to reveal > related / child controls. > This is bad design impacting everyone and surely an accessibility barrier. > Thanks and respectfully, > Sailesh > > > -- Sailesh Panchang Customer Success Strategist and Principal Accessibility Consultant Deque Systems Inc 381 Elden Street, Suite 2000, Herndon, VA 20170 Mobile: 571-344-1765
Received on Wednesday, 27 April 2022 15:33:00 UTC