Re: Visual Indicators

Hi Stefan,

"...who should do what with reasonable effort..."


OK. What (and who) defines "reasonable"? (That BTW, is a serious question)

And reasonable to whom? the end user? the content creator? the site
evaluator? the non-technical legislative official? the judge? (who's judge?
A German judge? A French judge? An American judge? An Australian judge?...)

This is not as simple as it may sound.


Also, if there is a common override concept for CSS styles to be used in
user agents (a list what css attributes should be overridable to enable
customization for WCAG requirements) I also think that WCAG should lay
foundation to this.

So, respectfully, I think there may be some confusion about the role the
Accessibility Guidelines Working Group plays within the larger ecosystem.
What you are alluding to here would likely first have to start in the CSS
Working Group (or maybe the joint CSS Accessibility TF
<https://www.w3.org/WAI/APA/task-forces/css-a11y/>?), and would likely need
to have the support of the browser vendors. I will suggest that this
activity, at this time, is out of scope for this WG.

The role of *this* working group (per our Charter
<https://raw.githack.com/w3c/wcag/charter-2019/charter.html>) is:

   - Develop Web Content Accessibility Guidelines (WCAG) 2.2 to address
   gaps in WCAG 2.0 and WCAG 2.1 related to content with a particular focus on
   users of mobile devices and people with low vision or with cognitive
   disabilities.
   - Continue development of a repository of test rules that uses the
   Accessibility Conformance Rules Format, to promote a unified interpretation
   of WCAG 2.x among different web accessibility test tools.
   - Develop a new standard (name to be decided) to succeed WCAG 2.x based
   on the work of the Silver Task Force. The goal is to provide information
   that can be used to improve the accessibility of products when using the
   guidelines on a variety of platforms. As noted in the Draft Requirements,
   it will use a different framework to allow it to address more disability
   needs, address publishing requirements and emerging technologies on the web
   such as web XR (augmented, virtual and mixed reality) and voice input. It
   will provide non-normative information about the ways web technologies need
   to work with authoring tools, user agents, and assistive technologies. This
   framework is intended to support better coverage across disabilities, and
   be easier to maintain, so that the new framework will be more durable over
   time as technologies evolve. This will require development of a new
   conformance model, engaging policy makers in that process, and testing the
   model with policy makers from different settings.
   - Maintain Authoring Tool Accessibility Guidelines (ATAG) as needed.
   - Continue development of non-normative documents to support
   implementation of accessibility guidelines.

*That's it*, and I can suggest that the W3C membership (and management) do
not look favorably on scope creep, so any additional work would first need
to find a home, and be sure that it is in scope for whatever home if finds
- again I suspect CSS Accessibility TF would likely be the initial place
for that:

The CSS Accessibility Task Force (CSS A11Y TF) is a Task Force of the
Accessible
Platform Architectures Working Group (APA WG) <http://www.w3.org/WAI/APA/>,
the Cascading Style Sheets Working Group (CSS WG)
<https://www.w3.org/Style/CSS/>, and the Accessible Rich Internet
Applications Working Group (ARIA WG) <http://www.w3.org/WAI/ARIA/>. It
assists these Working Groups to address accessibility to people with
disabilities where impacted by features of Cascading Style Sheets.


So, it's not so much that I am seeking to frustrate making the web more
accessible, but rather I want to ensure that we get there with due and
deliberate consideration, that we do so within the framework that the W3C
has afforded us, and that we are realistic on what (and how much) we demand
of content creators of all sites: the SAP's, Googles, Adobe's and Amazon's
of the world, as well as the 3-page site for the flower shop down the road.
Putting all of the heavy lifting on the content creator is both unfair and
unrealistic, and WILL fail.

(I'll further suggest that the CSS Accessibility TF could use some
additional hands to keep up with ongoing work, never mind pursuing new
initiatives, and if you feel this idea is really important, I would urge
you to reach out to that TF and get involved there).

The bottom line for me is that I believe we will fail whenever we attempt
to try and modify author behavior by writing a SC with the hopes that it
will be legally mandated. It just doesn't work that way.

Respectfully

JF

On Thu, Apr 16, 2020 at 12:19 PM Schnabel, Stefan <stefan.schnabel@sap.com>
wrote:

> Hi John,
>
>
>
> Thanks for asking this. I think it is mainly about rephrasing the
> following:
>
>    - 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.
>
> I cannot shoot from the hip but I might come up with a more elaborated
> phrasing in a timely fashion.
>
>
>
> The point is simply to clarify “who should do what with reasonable
> effort”. For instance, it is not practical (although doable) if users write
> Bookmarklets that link labels to form fields if authors have forgotten
> that. We are also talking about usability here. The current example
> Bookmarklet for text spacing is for instance not working in iframes
> included in page, should users really fix that on their own only because
> they can in principle? Don’t think so.
>
>
>
> Also, if there is a *common override concept fo**r CSS styles to be used
> in user agents* (a list what css attributes should be overridable to
> enable customization for WCAG requirements) I also think that WCAG should
> lay foundation to this, with custom text spacing metrics being an
> important building block.
>
>
>
> Best Regards
>
> Stefan
>
>
>
> *From:* John Foliot <john.foliot@deque.com>
> *Sent:* Thursday, April 16, 2020 6:47 PM
> *To:* Schnabel, Stefan <stefan.schnabel@sap.com>
> *Cc:* Alastair Campbell <acampbell@nomensa.com>; Niemann, Gundula <
> gundula.niemann@sap.com>; David MacDonald <david100@sympatico.ca>; WCAG <
> w3c-wai-gl@w3.org>
> *Subject:* Re: Visual Indicators
>
>
>
> Stefan writes:
>
>
>
> "...Being late to the party, I’d like to see a respective sentence to be
> added in the requirement to be more precise and avoiding ambiguities in
> interpretation."
>
>
>
> Hi Stefan,
>
>
>
> Would you care to offer a draft example of what kind of sentence you'd
> like to see?
>
>
>
> We need to be careful here, as the W3C has neither the remit or power to
> *force* browsers to do anything (which is one of the reasons why continued
> work on UAAG has stopped). That said, there *ARE* browser extensions that
> allow for this functionality today, so I am a bit unclear on what you
> consider to be ambiguous.
>
>
>
> JF
>
>
>
> On Thu, Apr 16, 2020 at 10:55 AM Schnabel, Stefan <stefan.schnabel@sap.com>
> wrote:
>
> “We do not expect end users to dig into code to implement this, but it
> would be something for a user-agent (e.g. plugin) to take up.”
>
>
>
> Being late to the party, I’d like to see a respective sentence to be added
> in the requirement to be more precise and avoiding ambiguities in
> interpretation.
>
>
>
> Also, I raised the point to add this to requirements for user agents as
> for instance, the WAI-ARIA 1.0 User Agent Implementation Guide
> <https://www.w3.org/TR/wai-aria-implementation/> once did and the Core
> Accessibility API Mappings 1.2 <https://w3c.github.io/core-aam/>
> continues. The fact that the User Agent Accessibility Guidelines (UAAG)
> <https://www.w3.org/WAI/standards-guidelines/uaag> evolvement seems to be
> idle since 2016 does not change this.
>
>
>
> Regards
>
> Stefan
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Thursday, April 16, 2020 4:47 PM
> *To:* Niemann, Gundula <gundula.niemann@sap.com>; David MacDonald <
> david100@sympatico.ca>
> *Cc:* WCAG <w3c-wai-gl@w3.org>
> *Subject:* RE: Visual Indicators
>
>
>
> Hi Gundula,
>
>
>
> I think we are agreeing in general, but there are a couple of things to
> point out for future, and in relation to other SCs.
>
>
>
>
>
> > it was clearly stated that the WCAG should not be prescriptive
>
>
>
> We do try to avoid being prescriptive about design aspects, but we also
> have minimum contrast requirements. It is not a binary thing, there are
> exceptions.
>
>
>
>
>
> > which contradicts to the below suggestion to determine exactly how a
> link or button should show their nature.
>
>
>
> The suggestion was to treat it like text-spacing, where it is *not*
> prescriptive about the design. It asks that if the user adapts the design
> in a specific way, it does not become unusable.
>
>
>
> We do not expect end users to dig into code to implement this, but it
> would be something for a user-agent (e.g. plugin) to take up. For example,
> there isn’t a plugin to specifically implement text-spacing, but there are
> several for changing fonts. I have a dyslexic (aimed) one installed in
> Chrome which changes the font, which impacts the spacing.
>
>
>
> Anyway, we are generally agreeing, I just wanted that to be clear.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
>
> --
>
> *​**John Foliot* | Principal Accessibility Strategist | W3C AC
> Representative
> Deque Systems - Accessibility for Good
> deque.com
>
>
>
>
>


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