Re: Plugins as SC - thread was: Visual Indicators

Hi Stefan,

So, I'll start by saying I think we are fundamentally on the same page,
with some minor differences in expectations.

As I noted in a previous email to Jon Avilla, I concur that for many of us
(who've been around for any length of time) we all recognized the important
role that tool vendors play in the ecosystem.



I just say if making plugins with user settings or modifications an
integral part of requirement SC concept *is dangerous *since it removes the
need for the layers above to do **anything**. They will always argument
“yeah yeah take a plugin and you’re good” (for screen readers, you
practically have no other choice).


While I fundamentally agree with this sentiment, I believe that a)
demanding or creating specific types of assistive technology is widely (and
wildly) out of scope for this Working Group, and b) the "*...start with a
browser extension as a PoC and prove the need...*" perspective is one that
the browser vendors are advocating, not I. It appears today that there are
3 ways of effecting change in browsers: create an extension that proves a
need is not being met, file a bug in the browser vendors bug-trackers and
hope they fix it, or legislations sue the browser vendors to provide the
functionality (ref: Microsoft's European worries). *None of those options
involve the content author!*

Unfortunately, in the absence of the browser vendors or other tool-makers
filling the gap, we have to either accept extensions, or accept that today
some things cannot be achieved in the tools. *We cannot however make all of
that the problem of the content provider.* Yes, they have a role to play,
but they cannot fix all problems for all users simply by following very
narrow and constrained "You Must Legally Do" requirements.

As such, I am in complete agreement with Patrick Lauke when he wrote:

The requirement (and the only thing possible for authors) is that the
authored content should not try to actively suppress/stand in the way/not
provide the necessary programmatic hooks that allow users to get to the
necessary end result.

(...although I disagree with his somewhat flawed understanding and
interpretation of SC 1.3.5, but that's for another beer...)

At the end of the day however, I will continue to maintain that "actively
getting the browser vendors and other tool makers involved", while critical
to the larger effort, remains outside the scope of this Working Group. I'd
love to figure out how to better include those constituents into our work
(but I'll suggest that starting out with "you NEED to do this, that and the
other" is likely not the best starting point to begin the conversation).

I welcome thoughts on how to get those folks to the table.

JF

On Fri, Apr 17, 2020 at 3:58 AM Schnabel, Stefan <stefan.schnabel@sap.com>
wrote:

> Hi John,
>
>
>
> (Changing subject to Plugins as SC (because this fits better))
>
>
>
> Many thanks for your detailed and comprehensive answer. I really
> understand the group scope better now – great overview!
>
> Nevertheless I’d like to comment on some aspects in your answer.
>
>
>
> First, I am not talking about legal stuff although there is a strong one
> despite of the charter.
>
> I know that a “who should do what” in requirement text violates the
> charter. But I think then the charter needs an refresh. But that’s another
> discussion.
>
>
>
> I am a tech guy and my interest is to have a clean design and testable
> statements.
>
>
>
> And I am fully in the camp of removing the burden from the end user and
> put it to other levels.
>
>
>
> Basically, a WCAG requirement "...who should do what with reasonable
> effort..." is handled for me on different levels that built on each other:
>
>
>
>    - OS foundation (settings, services)
>    - User Agent features (using foundation but also own functions)
>    - Framework (encapsulating requirements by using user agent and markup
>    language features)
>    - Web Application / Web Page author (the rest)
>
>
>
> Note that in the overview USERS are missing. They just apply settings
> offered by the other levels. That’s okay and should stay so in my opinion.
>
>
>
> Additionally  is now the idea for certain requirements of having users
> need to install plugins that extend User Agent features and maintain their
> needed settings there. Doing so, it is comparable to “install a screen
> reader if you need more support”.
>
>
>
> I just say if making plugins with user settings or modifications an
> integral part of requirement SC concept *is dangerous *since it removes
> the need for the layers above to do **anything**. They will always
> argument “yeah yeah take a plugin and you’re good” (for screen readers, you
> practically have no other choice).
>
>
>
> The problem that comes up immediately is a plethora of different plugins
> offering different levels of support. You have to install one for better
> focus rendering, for text spacing, for font sizes etc. Sure, swiss-army
> knives plugins will pop up but who decides what they should support? I’ve
> seen too much of them specialized on something, failing in other aspects
> and so on. *“Let the market regulate that” is not good here in my
> opinion.*
>
>
>
> And there is always your SC in
> https://www.w3.org/WAI/WCAG21/Techniques/css/C36
>
>
>
>    - Check that all content and functionality is available e.g., text in
>    containers is not truncated and does not overlap other content.
>
>
>
> The problem here is even when you use tools the Procedure 3 MAY GOT
> VIOLATED since the app needs to be ready for this. You will spawn endless
> discussions with developers blaming the tools etc.
>
>
>
> *As a bottom line, I don’t like having plugins doing jobs like font
> resizing, focus enhancements and text spacing and I think these features
> are best to be encapsulated in content builder frameworks, if not in user
> agents itself. And somehow WCAG should say so.*
>
>
>
> This is what I meant with rephrasing C36 procedures. You ask me for an
> alternative version, so here it is. It is combined with the layer approach
> above.
>
>
>
> https://www.w3.org/WAI/WCAG21/Techniques/css/C36
>
>
>
> *Tests*
>
> *Procedure*
>
>
>
> *Definitions*
>
>
>
>    - *Text spacing metrics: changes should include(line height, and
>    paragraph, letter, and word spacing.*
>
>
>
> *Prerequisites*
>
>
>
>    1. *Set zoom level to 100%.*
>    2. *Check if elements with text are following responsive layout
>    principles (text is intended to wrap or will push text container borders if
>    modified)*
>
>
>
> *Test*
>
>
>
> *Check if support for text spacing metrics changes is available*
>
>    1. *in operating system*
>       2. *in user agent (browser)*
>       3. *in content builder frameworks (such as WordPress)*
>       4. *as part of web application/page *
>       5. *as user agent plugin (such as the Text Spacing Bookmarklet or a
>       user-style browser plugin) *
>
> *with all content and functionality still available e.g., text in
> containers is not truncated and does not overlap other content.*
>
>
>
> The sequence above give clearly precedence to a certain expectation who
> should do what with plugins as last resort.
>
>
>
> With all respect + best regards
>
> Stefan
>
>
>
> *From:* John Foliot <john.foliot@deque.com>
> *Sent:* Thursday, April 16, 2020 11:42 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
>
>
>
> 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 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, 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
>
>
>
>
>


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