Re: Conforming alternative for mobile should not be Desktop

>>>(Q: do we make as a conformance condition that in a use-case like this,
both"views" must meet the same conformance level? i.e. a "mobile" (sorry
Patrick) site that claims conformance to WCAG 2.1 by, in part, relying on
pointing to WCAG 2.0-only content, explicitly does NOT meet WCAG 2.1
conformance. Seems obvious, but should we document that somewhere?)

BINGO! That is ALL this entire thread is about. And yes it is about 2.1.

If this conforming alternative language gets into 2.1 without the
amendments I'm proposing (or some other way to fix it), NOTHING that is
sent specifically to Mobile view has to conform, if another "conforming
alternative" can be accessibility found on the page.

So say I'm blind, with a bit of vision, I'm in Walmart, and want to look up
a product, pull out my phone go to the site... it serves up the mobile
view. The search field, and hamburger menu don't work, so I can't do
anything on this page ... so I go looking for a link to the desktop view,
hoping that view conforms. 5 minutes gone... get to desktop view on my
mobile device, let's assume it conforms to the new shiny WCAG 2.1,  I still
have a lousy experience, because they didn't optimize it for mobile. Big
images suck up my bandwidth, costing me more money that other users, tons
of content to swipe through, thick mega menu, I have no keyboard so I'm
using the rotor to sift through the big site with all kinds of extra
content. I'm outside, I'm on the go, just trying to look something up.

This is ALL I want to solve.


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 Wed, Jun 29, 2016 at 1:35 PM, John Foliot <john.foliot@deque.com> wrote:

> Hi all,
>
> I have to agree with Patrick here. If the goal is to try and apply some
> type of retro-active SC requirement language to WCAG 2.0 to address known
> and seen issues in the wild today, I start getting twitchy: any move that
> makes sites that are compliant today to WCAG 2.0 (usability put aside for a
> minute) non-compliant tomorrow is a deal-breaker, so for clarity sake, this
> newly proposed language and 'conditions', while I agree are important, are
> only applicable to sites claiming WCAG 2.1 conformance - correct?
>
> If this is the case, then yes, we can strengthen the definition language
> by modifying an existing 'point' (David's proposed Point 2 edit) or by
> adding a new 'point' (the proposed Point 8 definition). However, as Patrick
> points out, WCAG 2.1 will also include requirements that have emerged for
> small-screen/touch devices that, when written well (platform agnostic) then
> the requirements for a compliant WCAG 2.1 site will be applicable for both
> of the 'views' we are discussing, whether optimised for large-screen or
> small-screen use: in other words www.site.com and m.site.com will both
> need be conformant to WCAG 2.1 when invoking that 'clause', so where is the
> issue?
>
> (Q: do we make as a conformance condition that in a use-case like this,
> both"views" must meet the same conformance level? i.e. a "mobile" (sorry
> Patrick) site that claims conformance to WCAG 2.1 by, in part, relying on
> pointing to WCAG 2.0-only content, explicitly does NOT meet WCAG 2.1
> conformance. Seems obvious, but should we document that somewhere?)
>
> JF
>
> On Wed, Jun 29, 2016 at 11:53 AM, Patrick H. Lauke <redux@splintered.co.uk
> > wrote:
>
>> On 29/06/2016 17:33, David MacDonald wrote:
>>
>>> So even if there are "more content", "additional interface elements"
>>>>>
>>>> etc in the alternate version, it counts as alternate version under the
>>> current definition/note 2.
>>>
>>> I'm not sure. That was my original assumption. However, it says multiple
>>> pages, it doesn't say "more complicated, bandwidth heavy, complicated
>>> menu, etc..."
>>>
>>> But I agree it is a concern worth addressing.  I know I've been on the
>>> fence about failing messed up hamburger menus. I usually say "fixing it
>>> lowers the risk of complaint"
>>>
>>
>> Why? If a hamburger menu is messed up (its trigger doesn't expose the
>> correct role, aria-expanded, it doesn't handle focus correctly when
>> opened/closed, etc) then it fails WCAG. What's that got to do with this
>> discussion?
>>
>> Note 2: The alternate version does not need to be matched page for page
>>>>
>>> with the original (e.g., the conforming alternate version may consist of
>>> multiple pages). <add>However, it should not force the user to navigate
>>> to a view optimized for another platform.</add>
>>>
>>
>> At the risk of dragging this out even further, I don't think I agree with
>> this. Whether something is "optimized" or not does not mean it's accessible
>> or not. And again, if the alternative is accessible, it'll also be
>> implicitly "optimized" as far as WCAG 2.1 demands (once the other SCs are
>> in place).
>>
>>
>> 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
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>