RE: Moving Issues 62, 63, 71 to the conformance section

Steve: In other words, why is there no requirement to label it as the accessible alternative and to tell the user what is gained by using it?  This seems like a shortcoming to me, so I opened a new GitHub issue: https://github.com/w3c/wcag21/issues/306


David: Yes its a hole, but for me I'd like to get some sort statement in WCAG 2 as per #197  (1) or in 2.1 as per issue #19 (2) that ensure there is no ambiguity about responsive sites having to conform at each breakpoint.

I agree, but I see that both are needed rather than either one or the other.  I believe they will complement one another in practice by weeding out bogus claims and enhancing legitimate alternatives.  As a screen reader user, it’s actually a fairly frequent problem to come across a link to the supposed more accessible version or to check some box to turn on accessibility enhancements, yet more often than not I find I can use the original just fine or I need to manually investigate what is different.  If a site is cognizant enough to create a conforming alternative, they should be cognizant enough to tell the user where the differences would be found.

Steve

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Sunday, July 16, 2017 4:45 PM
To: Repsher, Stephen J <stephen.j.repsher@boeing.com>; Jonathan Avila <jon.avila@ssbbartgroup.com>
Cc: Patrick H. Lauke <redux@splintered.co.uk>; w3c-wai-gl@w3.org
Subject: Re: Moving Issues 62, 63, 71 to the conformance section

Patrick says:
> When did I make this addition? Is this going back to that discussion 2 years ago or whenever?

David
Yes that's right.  https://github.com/w3c/wcag/issues/197#issuecomment-229927329

Patrick:
>If the user changes their user agent's zoom setting then they haven't used a "setting ON the page" but in their UA, so that won't be a loophole?

Does that satisfy your concern Jonathan?

Steve
>  In other words, why is there no requirement to label it as the accessible alternative and to tell the user what is gained by using it?  This seems like a shortcoming to me, so I opened a new GitHub issue: https://github.com/w3c/wcag21/issues/306


Yes its a hole, but for me I'd like to get some sort statement in WCAG 2 as per #197  (1) or in 2.1 as per issue #19 (2) that ensure there is no ambiguity about responsive sites having to conform at each breakpoint.


(1) https://github.com/w3c/wcag/issues/197

(2) https://github.com/w3c/wcag21/issues/19








Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Sun, Jul 16, 2017 at 12:22 PM, Repsher, Stephen J <stephen.j.repsher@boeing.com<mailto:stephen.j.repsher@boeing.com>> wrote:
Thanks for the explanation, David, and for the history, Patrick.  Alright, if there's a link to a conformant version, then I suppose there's certainly complicated gray area.

The first question in my mind though is not complicated: How am I supposed to know that the link to the desktop version is the conforming alternative?  And how do I know I need to use it other than wasting time with trial and error?  In other words, why is there no requirement to label it as the accessible alternative and to tell the user what is gained by using it?  This seems like a shortcoming to me, so I opened a new GitHub issue:

https://github.com/w3c/wcag21/issues/306


Steve


-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk<mailto:redux@splintered.co.uk>]
Sent: Sunday, July 16, 2017 8:44 AM
To: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Subject: Re: Moving Issues 62, 63, 71 to the conformance section
On 16/07/2017 13:27, David MacDonald wrote:

> Many mobile pages have a difficult to find (but conforming) link at
> the bottom called "desktop version". This loads the desktop version
> into the mobile browser.

That loads a different set of HTML/CSS/JS into the browser. So it's a completely separate version (usually on a different web address, or on the same address but it sets a cookie, or similar).

Reponsive/adaptive sites on the other hand don't offer a "switch". They simply "are"...they adapt to whatever the environment in the client is, and dynamically change as the environment changes. So we argued (many many moons ago...2 years ago or so on the mailing list?) that it's not a different version in this case, since the page is still exactly the same, it just changes.

There's obviously gray area here in cases where the same URL does some server-side detection and, even though it's the same URL, serves different content depending on things like user agent...but in general I thought we agreed that unless there's an explicit mechanism on the page (like a "go to desktop version / go to mobile version") that the user can toggle to force loading of a specific alternative view, then the page counts as a single page, and its different states triggered by things the user can't easily control (e.g. screen size, user agent string, presence of a sensor or not) cannot be treated as separate alternatives.

P
--
Patrick H. Lauke

www.splintered.co.uk<http://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