- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Fri, 28 Apr 2017 14:43:06 +0000
- To: John Foliot <john.foliot@deque.com>
- CC: "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <4FAF9408-EDA7-4F56-8C60-55C65760CD53@nomensa.com>
Hi John, Heh, I’m in half agreement, specifically I agree that the delivery protocol not relevant these days. But: > The Mobile Accessibility Task Force proposals cover both "web" content, "web apps" and Native apps I don’t think they have tried to cover native apps (MATF – please correct me if you did?!) The quote with my emphasis: “the guidelines and success criteria may also apply to native mobile applications.” That is key because if you commit to covering something you need to be restricted by it’s capabilities (and there go headings). There are already guidelines from the platform providers, and when we assess iOS/Android apps we use the principles from WCAG plus the platform guidelines. We haven’t found WCAG directly applicable in many cases, a translation process is needed. Also, I’m not sure but you seem to confuse PWA & native? To clarify (probably for other people), there is a scale from website to app on mobile: - A traditional website rendered in the browser of a mobile device. - A ‘Progressive Web App’ (an umbrella term for various recent technologies including offline stuff) that opens in the browser, but is optimised for mobile devices and it may not show the browser chrome. - A native app wrapper around an HTML based app, often using a framework to minimise the differences between iOS and Android. These are not opened in the browser but it may use the same (or very similar) rendering engine. - A native app that loads HTML views, not in the browser but it may use the same (or very similar) rendering engine. These may or may not load from the internet. - A native app with nothing to do with the internet or web (W3C) technologies. For me, the switch from just using WCAG to where it needs translation is when it doesn’t open in the browser, as the capabilities of the user-agent & assistive technology change. In terms of “fit”, WCAG fits technologies which have a consistent user-agent and a separate content/functionality delivery that the UA requests over the internet (whatever protocol). So the HTML (stack), PDF, and ePub all fit quite nicely. Flash & Silverlight somewhat fit, mostly because they were delivered within the browser context. It was very creaky though. Mobile apps and Java web start don’t really fit, or rather they might not fit at all if they are downloaded one time and don’t load any content/functionality over the internet. They somewhat fit if they are mostly rendering ‘web content’ (i.e. HTML stack) and provide a similar accessibility API as browsers to assistive technology. If we were starting fresh I’d suggest basing the definitions on web technologies that have a specific type of user-agent, but we aren’t starting again yet. So I just suggest we use the current definitions, perhaps with a tweak in that direction. E.g: Web Page …the term "Web page" includes an immersive, interactive movie-like experience found at a single URI and rendered in a standard user agent. content (Web content) … to be communicated to the user by means of a standard user agent… And a “standard user agent” means one that is cross-platform and used across ‘web sites’, rather than being unique per website. That tweak narrows WCAG 2.1 so I think is backwards compatible. (I.e. there is nothing being added to the scope, if anything, less technologies fit the scope.) Cheers, -Alastair
Received on Friday, 28 April 2017 14:43:42 UTC