Re: Visual Indicators

Jon writes:

> So in reading these responses it sounds like the desire is to not go
through with this success criterion because buttons, links, controls, etc.
can potentially be styled by the browser or user.

I think Jon that the concern (at least my concern) is that if we get overly
prescriptive of how/what these components MUST look like, we'll get
increased pushback.

I personally think that the key here is "programmatic determination" as
opposed to "human determination / perception" because each human is unique
and different, but machines generally are dependent on patterns, so that (I
believe) is where we (and content authors around the globe) can have the
most impact.

So for me, getting good patterns into our code is far more critical than
"styling", which yes, can be changed by the end-user today (albeit not as
simple as it could or should be) - which is why none-the-less the
Personalization work at the W3C is focused on new attributes that helper
apps could then leverage to meet the needs of individuals.

I become quite concerned when I read statements such as "Using clear,
salient, visual indicators..." because we do not have an agreed-to
definition of "clear" nor "salient", and for non-sighted users what do
those terms mean for them? (as "visual" is already a non-starter)
Additionally, what is "salient" for users who are dependant on symbols and
symbol-sets as *their* 'language'? And in another emergent SC, we have
currently *5* suggested levels or types of "Help" - how do we visually
account for those differences (do we need to?) Contrast that with some of
the emergent proposed attributes in the Personalization work
<http://w3c.github.io/personalization-semantics/content/index.html>, where
links and buttons would be tagged with metadata related to purpose, action,
destination, etc., and I remain convinced that some of what is being asked
for now can't scale or is overly prescriptive.

I recognize that at this time, this Personalization work is still pre-beta,
and cannot be relied upon to solve real problems today. But I personally do
not believe that trying to shoe-horn in a SC now that is overly
prescriptive and that still has what I see to be 'holes' in it is the right
path forward. But that is just me, and if the workig group wishes to
continue to pursue this, I won't be the blocker.

But as Andrew noted, if we get too prescriptive, it likely won't just be
"old opinionated Foliot" pushing back <grin>. FWIW

JF

On Thu, Apr 9, 2020 at 11:13 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Gundula,
>
>
>
> > The point is, a link with a luminance difference as indication for its
> nature and without underline passes SC 1.4.1, while it would not pass the
> current wording of the SC on visual indication.
>
>
>
> Agreed, but that is the point of the new criteria. There are lots of
> things that pass previous criteria that we are trying to tighten up.
>
>
>
> What you are pointing out would mean adjusting the supporting
> documentation for 1.4.1, but it wouldn’t be a blocker for the new SC.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>


-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com