Re: Conforming alternative for mobile should not be Desktop

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
>
>
>