Re: Mechanism Disclaimer

Point taken. Question is there ever an instance that the author has to code
a mechanism? That would easier for our work, because none of our SCs expect
the author to code a mechanism.

Good, Wayne


On Fri, Jan 20, 2017 at 5:24 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø 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.
>
>
>
> Wayne, I don’t agree that the author is always responsible for the
> mechanism in SC 2.4.1  The author could use headings or iframes and if the
> user agents supports keyboard access to those then the author isn’t
> responsible for providing skip links as the user agent may provide keyboard
> navigation to jump to these elements.  Often this isn’t the case – but in
> some cases it available via the user agent.
>
>
>
> Jonathan
>
>
>
> *From:* Wayne Dick [mailto:wayneedick@gmail.com]
> *Sent:* Friday, January 20, 2017 2:58 PM
> *To:* John Foliot
> *Cc:* Patrick H. Lauke; WCAG
> *Subject:* 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
>
>
>