Re: Mechanism Disclaimer

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