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

I can support that.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

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

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 Mon, Jul 17, 2017 at 12:08 PM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> wrote:

> 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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> 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]
> Sent: Sunday, July 16, 2017 8:44 AM
> To: 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 | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>
>