Re: Mechanism Disclaimer

Patrick wrote:
> I'm wondering what the relationship to, say, native apps would be, 
> where the OS likely doesn't provide mechanism, and authors 
> WOULD have to code something up themselves - or were these exempt even 
> in the current wording?)
   
Well, we’re covering web-content rather than native apps, but I think the point stands because extensions are not commonly supported on mobile browsers. (NB: Bookmarklets work on mobile, except for sites with CSP.)

There’s been a lot of discussion about that, with some justifiable resistance to including exceptions for user agents.

My view is that if the author tests their *content* for handling font-family changes, it doesn’t matter if some user-agents don’t support doing. It is a content guideline, and it is up to the user to have an agent that supports their needs. 
I think the proposed wording fits with that?

In the low-vision context most people don’t use small mobile devices simply because they don’t provide a usable interface for them, at least on the more moderate-to-severe end of the scale. (There are of course exceptions & exceptional people!)

However, I’m keen to translate user-requirements to content guidelines, and this seems like a necessary step to overcome the “OMG Widgets!” response. (That’s not a criticism, that’s the reaction I had initially to.)

Just because something isn’t supported on mobile doesn’t mean we shouldn’t improve things on desktop, assuming that it doesn’t make the mobile experience worse for everyone else. I think that applies to Resize content and several other SCs as well.

Cheers,

-Alastair

Received on Friday, 20 January 2017 12:19:21 UTC