RE: Mechanism Disclaimer

> > JF wrote: >> 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. 
> They should be able to specify how text is displayed, and if a site (ab)uses font-family to provide icons, then it creates an issue. They can use images, SVG, the CSS content mechanism the default Wordpress theme uses.. there are many 'good' methods.

I agree with Alistair, if the user wants to change the font -- how could the user know that in this case the font is an icon and not text?  While there are some common methods that might be giveaways I'm not aware of a sure proof method other than what Alistair describes.

Alistair, can you provide more information on the CSS technique used by WordPress that you describe?

Jonathan

-----Original Message-----
From: Alastair Campbell [mailto:acampbell@nomensa.com] 
Sent: Sunday, January 22, 2017 8:46 PM
To: John Foliot
Cc: w3c WAI List
Subject: Re: Mechanism Disclaimer

I think this has been somewhat overtaken by the other thread about combining the user-adaptation SCs, but there are some interesting points:

JF wrote:
> ​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​. 

They should be able to specify how text is displayed, and if a site (ab)uses font-family to provide icons, then it creates an issue. They can use images, SVG, the CSS content mechanism the default Wordpress theme uses.. there are many 'good' methods.

When over-riding, you can't predict what classes the author uses for an icon, you have to over-ride all font-family styles.

This is a relatively rare issue, I think the techniques for the font-family SC will more around spacing issues caused by changing fonts.


> I am becoming increasingly concerned that this phrase - ‘mechanism is available’ - is fast becoming the new "Until user agents...",

I had already thought that's what 2.0 did instead, wasn't it? E.g. Bypass blocks, if user-agents supported landmarks for keyboard-users we wouldn't need skip links anymore, for many cases at least.

Overall, I think we should focus on what the content enables (or not), which means moving the user-adaptation ones on a bit.

Another example is that it might also mean removing the exception from Resize content:

> "The content of the Web page can be increased to 400% without loss of content or functionality, without two dimensional scrolling, with following the exceptions:
> - If the spatial layout of some the content is essential to that contents use, that part of the content is exempt.
> - If the user-agent fits the layout to the viewport and does not provide a means of reflowing content, two dimensional scrolling is exempt.

The second exception (essentially for mobile) is irrelevant if the /content/ enables 400% zoom. However, I think we do need to set a benchmark in the understanding & testing documentation.

Cheers,

-Alastair

Received on Monday, 23 January 2017 16:24:56 UTC