Re: Mechanism Disclaimer

First, to Josh.
Sorry, I got up late today. Many of you will be at home or in bed or both
when this arrives. Time Zones.

Well I think the ability to create bookmarklets and extension is recognized
as a mechanism. However, the original wording does appear to imply that the
author was responsible to create the mechanism.  This is the case in WCAG
2.0 sometimes. Like

*2.4.1 Bypass Blocks:* A mechanism
<https://www.w3.org/TR/WCAG20/#mechanismdef> is available to bypass blocks
of content that are repeated on multiple Web pages
<https://www.w3.org/TR/WCAG20/#webpagedef>. (Level A)

In this one the author is responsible.

So I thought if the function was made clear like:
The user can change xxx... Followed by an an exception that starts with

The author is not responsible when no mechanism is available on any user
agent for the target technology...

Something like that, then it is clear that things like JS extensions
provide the mechanism.

I only used Font-Family as an example.

Wayne

On Fri, Jan 20, 2017 at 10:37 AM, John Foliot <john.foliot@deque.com> wrote:

> Hi folks,
>
> TL;DR
>
>    1. I believe this thread has started to splinter into multiple topics,
>    and I would like to see it get back on track
>    2. I fully support the statement *"**If no mechanism exists..., then
>    the author has no responsible [responsibility] to create one."*
>    3. I have continued concerns that the current wording of this SC is
>    geared towards User Agents and not Content Authors, suggesting that the
>    current draft is in need of a re-write.
>
> **********
>
> So, there now seems to be multiple ideas emerging in this thread, and
> keeping track of them is getting difficult (at least for me). The original
> subject line (Mechanism Disclaimer), and the topic of Wayne's email was
> around the following:
>
> *SC: Font*
>
> *"The user can change the font family down to the element level, to any
> font family available to the user agent with the following exception. *
>
> *If no mechanism exists to change font family on any user agent for the
> target technology, then the author has no responsible to create one."*
>
> ​Respectfully, if we need to discuss whether or not people with low vision
> use mobile devices or not, can we start up a new thread? ​Likewise, I am
> thinking that the discussion around font-icons, while related, is also
> off-topic, as Wayne's focus was looking at the disclaimer text.
>
> While I fully support the idea that the author has no responsibility to
> create widgets to accomodate every use-case, I am unclear as to what a
> content author should be doing to meet this proposed SC, and I'd like to
> know the answer to that. If, between browsers, extensions/plugins and
> end-user behavior the problem can be addressed today, and "...the author
> has no responsibility to create one (a solution)", then what is the point
> of the Success Criteria? It very much feels like it is pointed at User
> Agents, and not Content authors.
>
> While we likely need a User Agent requirement that ensures that end users
> can, in fact, make that kind of micro-level change (down to the element -
> or I'd argue more accurately, element + any CSS selectors involved) both
> today and going forward, WCAG is sadly not the place for that - WCAG is
> about Content, not User Agents.
>
>
> > Because if the user does change the font displayed (e.g. in the browser,
> with an extension, bookmarklet etc), font icons can disappear when certain
> techniques are used by the author.
>
> ​But Alastair, if the current proposed SC suggests that the end user can
> change fonts down to the element level, and if nav class="mobile" is using
> a hamburger menu icon, then the end user should not - at the element level
> - be changing *that* font​.
>
> If the end-user does make that change and "breaks" things, what (if
> anything) can the content author do? There is an implied agreement between
> author and end-user to meet in the middle somewhere: the content author
> shouldn't be locking things down, or doing other stupid things that impedes
> users, but the end user needs to own some of the responsibility for also
> not doing something stupid or detrimental to their own user-experience,
> right?
>
> > I.e. avoid ‘mechanism is available’ because people see that as “OMG
> Widgets!”.
>
> Agreed. I am becoming increasingly concerned that this phrase - ‘mechanism
> is available’ - is fast becoming the new "Until user agents..
> <https://www.w3.org/TR/WCAG10/wai-pageauth.html#until-user-agents>.", and
> I believe that this Working Group needs to have a bright line between
> requirements on the content author, and other accessibility support
> requirements that are more appropriately delivered by hardware/software
> solutions, which as I understand things will be addressed in Silver. This
> is not about denying the need exists, but rather ensuring that it is
> addressed at the appropriate place.
>
> Getting back to what I see as the core 'raison-d'etre' of this SC, (and LV
> folks like Wayne, Jim, and Jon, please confirm):
>
> Content Authors should not be creating style-sheets that the end-user
> cannot over-ride, right down to the element level.
>
>
> This would then address the ability to change out specific font faces in
> any web document, at the most granular of levels, while also allowing the
> end user to preserve other font-faces (such as icon fonts) - two positive
> outcomes that would address the needs of the core constituency from what I
> can tell.
>
> Which brings (at least me) back full-circle to Wayne's initial question
> (regarding the disclaimer):
>
> *If no mechanism exists to change font family on any user agent for the
> target technology, then the author has no responsible to create one. *
>
> ​Wayne, I agree 100% with this statement​, as it reinforces the basic
> premise that WCAG is for content authors, and that we have zero expectation
> for content authors to be somehow creating "widgets" to address every
> user's use-case. The first part of the SC however is in need of a re-write
> to ensure we are focused on Content Author behaviors, and not User Agent
> behaviors.
>
> J
> ​F​
>
> On Fri, Jan 20, 2017 at 10:51 AM, Patrick H. Lauke <redux@splintered.co.uk
> > wrote:
>
>> On 20/01/2017 14:21, David MacDonald wrote:
>>
>>> So in layman's terms I think what the SC is saying is "Don't get in the
>>> way of user style sheets by sticking "!important" on classes of your
>>> style sheets."
>>>
>>
>> I think Alastair already tackled this, but to be clear: no, user agents
>> that implement proper user stylesheets (rather than simply trying to append
>> styles to the document, like certain extensions do) will still override
>> things even if marked as !important. Authors are following the correct and
>> expected CSS standard here, it's the extensions/user agents that need to
>> follow this as well.
>>
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>