Re: Conforming alternative for mobile should not be Desktop

Given Loretta's response, I think we can formalize this and unify expert
opinion with a small amendment to the Understanding Conformance document.

It seems this is not a change to the current WCAG 2, therefore we can
manage this with a sentence added to Understanding Conformance Criteria 2.
It doesn't need to be part of the normative document. It could read like
this:

"The full page includes each view of the page that is customized for
various devices, browsers, or screen sizes. Each of these views would need
to conform in order for the entire page to conform."

https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html


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 Thu, Jun 30, 2016 at 2:07 PM, David MacDonald <david100@sympatico.ca>
wrote:

> If every breakpoint delivered from the same URL is has to meet WCAG in
> order for the page to conform, then I would be very happy... and the issue
> becomes much less pressing...
>
> I think we have to dig into the documents and tap other veterans of WCAG
> who remember our discussions and maybe crawl the archives to ensure this
> ... I currently don't see anything in the SCs or Conformance claims that
> says every breakpoint of a web page (or every version of the same URL) has
> to conform... But it was not really an issue back in the day... now it
> is... and I would like to formalize our position to ensure this is clear...
>
> ====I wrote to Loretta, who was an editor on WCAG 2 who's opinion I
> greatly value with the following scenario====
>
> Company X has a responsive web site. It has 2 break points based on
> viewport size. A user on a mobile device gets the same site as as the
> desktop, except it has a Hamburger menu icon instead of the mega menu.
>
> The mega menu conforms to WCAG, the Hamburger menu does not. There is no
> link to the desktop version. Does this page conform to WCAG?
>
> Some feel that it currently passes because there is one accessibility
> supported solution. Others think that it does not pass because the user on
> the mobile device doesn't have a choice about which view they get, (unless
> there is an accessible link to the desktop -alternative conforming-
> version.)
>
> What are your thoughts? The question is important for decisions in 2.1
>
> =====
>
> **Loretta's response:**
>
> Just a quick response because I'm on vacation and can't investigate the
> historical record.
>
> We had a lot if relevant discussion when trying to define web page (or all
> the alternate terms we were considering). Part of the discussion was about
> web apps, which dynamically change what is delivered from the same URI. As
> I recall, we concluded that any version of the page that could be delivered
> from that URI had to conform in order to claim that the URI conformed.
>
> I think this generalizes to saying that all the break points must conform
> to claim that the URI conforms.
>
> But this is just my recollection. Sorry I can't point to a specific
> discussion.
>
> ========
>
>
> 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 Thu, Jun 30, 2016 at 1:02 PM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 30/06/2016 17:44, David MacDonald wrote:
>>
>>> In a responsive site you would not get a link to a ‘desktop’ version.
>>>>>
>>>>
>>> I think this is very common.  I have seen and evaluated many mobile
>>> sites with a link at the bottom of the page that says "Desktop version"
>>> and it just serves up the same URL, without the breakpoint for mobile.
>>>
>>
>> This is the point where we need to get technically accurate. There are
>> various technologies in play here (and this is why generic terms like
>> "mobile" only help muddy the waters):
>>
>> - use of responsive layout with CSS media queries - these will trigger
>> based on factors such as viewport/window width/height/pixel density; these
>> are also triggered by zoom settings, window size, etc (so on a "desktop"
>> machine, if i change my window size, or change my browser zoom, they will
>> be triggered). as the browser handles the switching of layouts/styles,
>> these sites will not have any kind of "switch to desktop version"
>>
>> - use of JavaScript-based queries (either old-school checks of the
>> windows's width/height, or more advanced uses such as window.matchMedia()
>> https://developer.mozilla.org/en/docs/Web/API/Window/matchMedia which
>> effectively allows the use of CSS Media Query syntax in JavaScript); these
>> will also be triggered (depending on their specific logic) on desktop if
>> browser window size is changed, user zooms, etc. These *may* provide some
>> form of link or switch that effectively disabled the JavaScript logic
>> responsible for doing the querying, but this is fairly uncommon to do
>>
>> - server-side solutions which check the browser's User Agent string (UA
>> sniffing) and, if it looks like it's a "mobile" device, generate completely
>> different markup (under the same URL) for the user agent; these sites can,
>> if the author has catered for it, have some form of link or switch to
>> bypass the UA sniffing and serve/force the "desktop" view
>>
>> Of these (there may even be subtle variations/combinations), only the
>> last one can really be classed as an "alternate". The other two are all
>> adaptations that happen directly on the client side, so count as a single
>> page. All states of this page need to conform in order to pass WCAG.
>>
>> I have an action item to ask other old timers to WCAG their opinions.
>>> But here is my thinking. If the page has just ONE, WCAG conforming view,
>>> then it passed WCAG. Someone can claim conformance to WCAG and in their
>>> internal conformance statement say "accessibility supported for us means
>>> JAWS and IE, and a 22" desktop monitor". This stack meets the
>>> accessibility support requirements of WCAG. But they have met any law or
>>> judge that requires this site meet WCAG.
>>>
>>
>> Then that is a problem to be tackled in the definition of "accessibility
>> supported" https://www.w3.org/TR/WCAG20/#accessibility-supporteddef - by
>> the same token, I could make a site that only works on a large screen and
>> fails on a small desktop screen. Again, this is not mobile specific. If
>> there's a hole in WCAG 2.x, it's a fundamental one that isn't just one of
>> "mobile vs desktop" (and as was touched on elsewhere in the thread also
>> extends to low vision, user customisation, etc).
>>
>>
>> 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
>>
>>
>>
>