Re: Visual Indicators

Jon,
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.

AWK: Not exactly – I’d like to see something that addresses the user need without being unduly prescriptive.

Certainly SC 1.4.3 would fall into this category as well because users can change the color of text – although from a user viewpoint it’s complicated without losing the whole theme of the page just to get 4.5:1 contrast text in one area.

AWK: Absolutely. I hope that someday we get to a point where the personalization technologies are at a point where the color contrast advice only applies to images of text.

I’d also add that screen readers and speech recognition can already provide access to items that aren’t in the focus order – so there a possibility that this could be overcome as well.   Whether something is in the focus order won’t prevent most screen reader users from accessing it with browse mode.

AWK: Sure, but of course keyboard access and focus order aren’t only a benefit to screen reader and speech recognition users.

Similarly, I heard people say that machine language detection is so good today that there isn’t a need for language indication either – so folks could say that requirement should be pulled as well.

AWK: I hope we can depend on language detection soon. That would be great. But even there I suspect that we would have a requirement that the information needs to be able to be identified with the correct language as we do today. Today we need to mark the language values but someday we won’t.

AWK

From: John Foliot <john.foliot@deque.com>
Sent: Thursday, April 9, 2020 9:29 AM
To: Jonathan Avila <jon.avila@levelaccess.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Visual Indicators

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

AWK writes:

"I support the user need and trying to identify an SC that addresses the need, but this may need to be handled by user preferences, personalization, or plugins. Firefox already allows users to set links to be underlined, so plugins aren’t even needed with that browser.

My core question is whether the existence of readily available tools that users can use to meet this SC would be regarded as sufficient. If not, I expect that this will not survive comments."

A huge +1

If I've learned anything over the past 20+ years of WCAG, it's that the more prescriptive we become, the more resistance we will encounter.

One of the core tenets of the on-going Personalization work is that the end-user will be responsible for the final 'rendering' so long as the code is properly marked-up to support the personalization. It is *NOT* the responsibility of the browser or content owner to address every need of every user, but rather for the content owner to provide the appropriate condition(s) for the personalization/customization to be had.

This is not unlike our expectation that when we furnish an "alt text" to a non-textual item, that the browser itself will not natively provide that alternative text to all users by default, but rather that the information is there if and when a specific user requires it.

JF

On Wed, Apr 8, 2020 at 6:49 PM Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:
From my read of the text contrast >= 4.5:1 could still be used to indicate links.   My request for inline links that are not part of process to be included can be removed if it’s going to cause the success criterion to not be accepted.  However, I suspect that objections from some would still remain to the SC as links including inline links can be used as part of a process and a process is pretty open term.

Point 1: The term process could be interpreted vary broadly.  The settings link in Google could be seen as part of a process – the process of changing a setting – setting the language, filters, or changing your password.  Even using the search feature of a website like Google might be considered a process – each part of the process is required to complete the activity of performing a search just like selecting a product from a site is part of a process of purchasing a product.  Activating a link to “bold” text might be a process – you have to select text, activate the “b” button in order to bold content.

Point 2: Similarly, if links are not inline but are part of a process and space around the element sets them apart – do they need some other indicator such as the “settings” link in Google.   Since spacing of elements can’t be used would this require the settings text link to have underline, icon or a border?     I assume yes – please correct me if I am wrong.

Point 3. An example in the document indicates that an input field that is required requires a border.  While I agree with this – the wording of the proposed success criteria doesn’t seem to cover this example if text spacing, font, size, etc. are not the differentiator.  Do we need to update the wording of the criterion to cover this or am I missing something?

Point 4.  Do we want an exception for controls where there is another control on the page that does meet the requirements but one control doesn’t and they both perform the same action?

Jonathan

From: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Sent: Wednesday, April 8, 2020 6:22 PM
To: David Fazio <dfazio@helixopp.com<mailto:dfazio@helixopp.com>>; Niemann, Gundula <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>; David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Visual Indicators

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

To clarify an aspect that I’ve been uncomfortable with: does this mean that we are requiring that text links have underlines?

As an example, see https://www.google.com/search?q=WCAG – there are no underlined links. Some links are blue (4.6:1 contrast against non-link text color so meets non-text contrast) and larger text. Since the links are larger text and appear as a result of appearing in a list of search results so there is a heightened expectation that there will be links, I expect that we will encounter a lot of push-back on requiring underlines.

Amazon.com is similarly free of links without underlines.

I understand that the SC doesn’t strictly require that links are underlined – each link could have a little link icon next to it also, or some other visual indication.

I support the user need and trying to identify an SC that addresses the need, but this may need to be handled by user preferences, personalization, or plugins. Firefox already allows users to set links to be underlined, so plugins aren’t even needed with that browser.

My core question is whether the existence of readily available tools that users can use to meet this SC would be regarded as sufficient. If not, I expect that this will not survive comments.

Thanks,
AWK

Andrew Kirkpatrick
Head of Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk


From: David Fazio <dfazio@helixopp.com<mailto:dfazio@helixopp.com>>
Date: Wednesday, April 8, 2020 at 2:58 PM
To: "Niemann, Gundula" <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>, David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Visual Indicators
Resent-From: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Wednesday, April 8, 2020 at 2:58 PM

I’d also like to suggest/request an edit to the exception “An underline is a sufficient indicator that a control is actionable.”

I would prefer this only apply to text links. otherwise I think it would be very problematic to our COGA user needs

DF
This message was Sent from my iPhone. Please excuse any typographic errors.

On Apr 8, 2020, at 11:37 AM, David Fazio <dfazio@helixopp.com<mailto:dfazio@helixopp.com>> wrote:
We have done a lot of work, this past year, to identify and address some critical user needs in COGA. In reference to this SC they would be:

Helping users understand what things are and how to use them;

Using clear and understandable content;

Preventing the user from making mistakes

Also:

As I briefly mentioned, when a user browses a page they rely on “top-down attention”. This is a voluntary, narrow minded, tunnel vision, effort that is driven by internal predispositions of what the user expects to find (what it would look like). In doing so, they filter out most all other information that doesn’t meet their predisposed expectations (we rely on past experiences for this). This creates a high probability of “inattentional blindness, which is failing to notice something because it doesn’t meet your internal, or sub-conscious, expectations. In order for a stimulus to catch your attention it must be “salient”. This means it must have some logical relationship to the background, as well as your internal expectations, while also having prominent characteristics that make it stound out as different.

Using clear, salient, visual indicators helps users reduce mental fatigue, because the content jumps out at you in a process known as “bottom up attention, which is involuntary. It also helps users understand content (what it is, what it does), and helps prevent performing the wrong action. Text links aren’t typically used to perform processes or functions. Buttons, and controls are, which probably sounds redundant.

So, I am in favor of expanding the scope.

David Fazio


From: "Niemann, Gundula" <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>
Date: Wednesday, April 8, 2020 at 9:36 AM
To: David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Visual Indicators
Resent-From: <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Resent-Date: Wednesday, April 8, 2020 at 9:36 AM

Hello David, hello all,

in fact we do not agree to widen the scope of the upcoming “Visual Indicators” Success Criterion to inline links in a block of text,
as inline links are handled in SC 1.4.1, and the Success Criteria should be free of overlaps.
For easier reference, I linked some documents which are relevant in this context.
Some are from WCAG 2.0, some are from WCAG 2.1.
Use of Color:
Understanding SC 1.4.1 (in WCAG 2.0)
Section Techniques and Failures for Success Criterion 1.4.1 - Use of Color
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html


Understanding Success Criterion 1.4.1: Use of Color
https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html


Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them
https://www.w3.org/WAI/WCAG21/Techniques/general/G183


F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision
https://www.w3.org/TR/WCAG20-TECHS/F73.html

https://www.w3.org/WAI/WCAG21/Techniques/failures/F73


Best regards,
Gundula

----------
Dr. Gundula Niemann
SAP Accessibility Competence Center
SAP SE





From: David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>
Sent: Dienstag, 7. April 2020 19:32
To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Visual Indicators

Hi all

On the call John Avila, John Kirkwood and Brooks said they would like to see the scope of the Visual Indicators SC widened. Here is my attempt to do that while not impacting current design conventions.

      Visual Indicators: For controls needed to progress or complete a process, and inline links in a block of text, differences in spacing between elements, typeface, font size, or font style are not used as the only visual means of conveying interaction.

             Exception: An underline is a sufficient indicator that a control is actionable.

https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit?usp=sharing


Cheers,
David MacDonald



CanAdapt Solutions Inc.
Mobile:  613.806.9005

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

twitter.com/davidmacd<http://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>


--
​John Foliot | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com<http://deque.com/>