Re: Mechanism Disclaimer

When this SC was written - it was expected that the author WOULD provide a mechanism.    For example — links the jumped over nav to the content.

It is ok to assume that features in browsers would provide the solution — IF common - free browsers do in fact provide that mechanism.

It is ok to make assumptions about AT if it is true of most AT. 

No SC should be worded with any USER expectations in them since there is no way for an author to assume something about all users. 

So  “the user can…” is not good language.  There is no way for an author to know if the ‘user can’ 
but 
“ a mechanism is available to the user that…. “  is OK.
or 
“ a mechanism is available that allows the user to… “  is ok 


Best


g


Gregg C Vanderheiden
greggvan@umd.edu



> On Jan 20, 2017, at 2:57 PM, Wayne Dick <wayneedick@gmail.com> wrote:
> 
> 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 <mailto:john.foliot@deque.com>> wrote:
> Hi folks,
> 
> TL;DR
> I believe this thread has started to splinter into multiple topics, and I would like to see it get back on track
> I fully support the statement "If no mechanism exists..., then the author has no responsible [responsibility] to create one."
> 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 <mailto: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 <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke>
> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
> 
> 
> 
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion
>