- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Fri, 20 Jan 2017 12:18:42 +0000
- To: "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
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