Re: Possible draft of 3.2.7

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