Re: WCAG 2.2 status - Visual indicators

>...provides visual information required to understand its purpose

I should mention that historically, we've been shy to assign attributes to
a user ... because what is required for one person may be different from
what is required by someone else... and it leads to an untestable SC.
There may be another way to make it testable... but historically this has
been our concern with SC proposals that reference the abilities of the end
user.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>


On Sun, Jan 19, 2020 at 5:53 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> > Is “active” stated to be more clear and direct than making an exception
> for inactive or disabled elements?
>
>
>
> I think it was intended to exclude inactive components, and it could be
> clarified, but I think the other issues are more pressing.
>
>
>
>
>
> Can this be described as “visible indicator” instead of “visual
> indicator”?
>
> As an adjective, visual implies that the indicator is related to sight,
> whereas visible implies that the indicator is able to be seen.
>
>
>
> I agree ‘visible indicator’ would equate to ‘able to be seen’, and then it
> would encompass any decorative elements that are part of the component.
>
>
>
> The closest concept we have in 2.1 is “Visual information required to
> identify user interface components”. (Which has been particularly difficult
> to apply across lots of different scenarios.)
>
>
>
> To keep it similar we could use something like:
>
> “Each active user interface component provides visual information required
> to understand its purpose”
>
>
>
> However, I suspect that there is not 100% overlap between *identifying*
> something, and understanding it’s *purpose*.
>
>
>
> That leads onto the next point:
>
>
>
> > Are there any methods, techniques and tests for “conveys its purpose”?
>
>
>
> No, nor do we have clear guidance on what appropriate visual indicators
> would be per component type. See the other thread on gathering examples [1].
>
>
>
>
>
> > Wrapping that icon with another visible bounding area that has a
> background or a border might (emphasis on might) indicate that it can be
> acted upon, but does not at all convey its purpose.
>
>
>
> That’s a good point, an icon used within a link may or may not be
> considered a visual indicator in itself, and whether someone understands it
> will vary by person/tester. Applying borders (or anything pre-defined) may
> or may not help.
>
>
>
>
>
> > Why is the second sentence necessary?
>
>
>
> I don’t think it is, unless someone knows why it was there (and doesn’t
> overlap with 1.4.11) then we can remove it.
>
>
>
> Overall, for the SC text aimed at providing visual indicators by default,
> there is a fair bit of work that needs doing, probably on the Silver
> timeline:
>
> 1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JanMar/0031.html
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>