Re: Visual Indicators

Gundala writes:

"...Requesting the end user to add visuals via style sheet is not an
option..."

Of course it is an option.

It may not be your preferred option, and it may not address all the needs
of all users, but it remains nonetheless an option. In fact,
*Success Criterion 1.4.12* (Text Spacing
<https://www.w3.org/TR/WCAG21/#text-spacing>)
<https://www.w3.org/TR/WCAG21/#text-spacing> is predicated upon the idea of
personalized style-sheets (individual users will use modified user style
sheets), and requires the ability to modify style sheets to test:

Test Procedure:

For elements which contain text that is intended to wrap:


   - Set zoom level to 100%.
      - Use a tool or another mechanism to apply the text spacing metrics
      (line height, and paragraph, letter, and word spacing), such as the Text
      Spacing Bookmarklet or a user-style browser plugin.
      - Check that all content and functionality is available e.g., text in
      containers is not truncated and does not overlap other content.

(see: https://www.w3.org/WAI/WCAG21/Techniques/css/C36.html)


JF

On Thu, Apr 16, 2020 at 8:38 AM Niemann, Gundula <gundula.niemann@sap.com>
wrote:

> Hello Alastair, hello all,
>
>
>
> it was clearly stated that the WCAG should not be prescriptive, which
> contradicts to the below suggestion to determine exactly how a link or
> button should show their nature. There are several options, specifically
> inside a toolbar, and buttons often reveal their nature by a colored
> background or on hover or focus.
>
>
>
> Requesting the end user to add visuals via style sheet is not an option,
> because
>
>    - It is unfeasible if the user has to redesign a web page to be able
>    to use it
>    - Most end users are not deep into web programming to perform such
>    changes
>    - The most common user agents to not support adding tweaked style
>    sheets
>    - Most web pages and applications are themed, and themes usually break
>    when adding tweaked style sheet classes/properties
>
>
>
> So we agree that there are too many questions open to go forward with this
> SC.
>
>
>
> Best regards,
>
> Gundula
>
>
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Donnerstag, 16. April 2020 10:19
> *To:* David MacDonald <david100@sympatico.ca>
> *Cc:* WCAG <w3c-wai-gl@w3.org>
> *Subject:* RE: Visual Indicators
>
>
>
> Hi David,
>
>
>
> It is an interesting idea, but we would really need to have a good idea of
> where that breaks at the moment.
>
>
>
> I’ve been running similar CSS [1] via Stylus (on and off) for a while, and
> generally it works. You might even say there is no need for an SC?
>
>
>
> Where it doesn’t work it is either because:
>
>    1. The correct markup is not used (generally a failure of
>    1.3.1/4.1.2), or
>    2. some random layout CSS hides some or all of the border/outline area.
>
>
>
> In the second (fairly rare) case it is really hard to see how to improve
> that without impacting the design. For example, you might have a ‘card’
> that contains an image link, and in the responsive design at some sizes
> you’ll have a border, but at others the card ‘contains’ the link and the
> borders are hidden.
>
>
>
> With the specific text chosen it also missed image links entirely,
> although that might be intentional?
>
>
>
> Personally, I think there are still too many questions open at this stage,
> and that is without addressing the question of whether a plugin-approach is
> suitable.
>
>
>
> -Alastair
>
>
>
> 1] https://gist.github.com/alastc/8f849456346cd08d6842d5d3c9c6dd0b
>
>
>
>
>
> *From:* David MacDonald
>
>
>
> Hi All
>
>
>
> I've added an OPTION 3 to the spreadsheet which is a fallback passive SC
> based on the text spacing SC ...
>
>
>
>
>
> Plain language:
>
> "Don't do anything that overrides a browser plugin's ability to override
> CSS to create outlines on buttons and underlines on links."
>
>
>
> In content implemented using markup languages that support visual
> adaptation of user interface components
> <https://www.w3.org/TR/WCAG21/#dfn-user-interface-components>, one of the
> following is true, with no loss of content or functionality, and by
> changing no other style property:
>
> 1.     A user agent or plugin can adjust:
>
> o   Button and input borders up to 3px (CSS) in width
>
> o   link underlines up to 2px (CSS) in width
>
> 2.     There is a mechanism available on the page where
>
> o   Button and input have borders with at least a 3:1 ratio
>
> o   link underlines with at least a 3:1 ratio
>
> 3.     On page load:
>
> o   Buttons and inputs have borders with at least a 3:1 ratio
>
> o   link underlines up to 1px (CSS) in width with at least a 3:1 ratio
>
>
> https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit?usp=sharing
>
>
>
> 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 Fri, Apr 10, 2020 at 12:20 PM Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi everyone,
>
>
>
> I’m trying to get to some conclusion from this thread, focusing on what
> people are suggesting to change (and to paraphrase people horribly):
>
>
>
>    - Gundula would like to widen the scope back to it’s original (all
>    controls provide affordance) but within a process, and avoid overlap from
>    referencing inline links.
>    - Andrew & JohnF are concern with requiring underlines/icons when
>    there are examples (like Google results) which would fail but appear to
>    have a clear expectation of being links (i.e. a false-fail). Design
>    push-back would also be expected. Personalisation seems a better option.
>    - JonA is concerned about defining what is part of a process or not.
>    - The COGA TF (via Rachael) are concerned the current version was
>    missing the intent and proposed a new version:
>
>
>
> “Interactive elements do not rely solely on spacing or a single visually
> identifiable characteristic to differentiate them from static elements,
> except for the following:
>
>    - An underline is sufficient to indicate a link is interactive
>    - A color difference is sufficient to indicate an element is disabled
>    - The control is part of a group of controls that has a visual
>    indicator for the group”
>
>
>
> My first impression of that update is that “a single visually identifiable
> characteristic” needs some explanation, I’m not sure how to apply that.
> Also, if the single characteristic were a border or background, wouldn’t
> that be ok?
>
>
>
> Overall, we seem to be oscillating between what we would like (the
> original affordances SC) and a very narrow version focusing on some
> specific aspects.
>
>
>
> The affordances version needs a huge amount of research/testing to define
> what visual aspects are needed to make something appear interactive.
>
>
>
> The narrower versions still suffer from creating false-positives and being
> very prescriptive about particular design aspects. IMHO being prescriptive
> isn’t necessarily a blocker, but if people can point to false positives
> then it is undermined.
>
>
>
> I’m struggling to see a path forward for this one on 2.2 timescales, we
> really need that research on what standard/core affordances are for various
> controls to align the SC/guideline text with the exact issues.
>
>
>
> -Alastair
>
>

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