Re: Conforming alternative for mobile should not be Desktop

*For example, what does a “different menu mechanism” mean? A “simplified
interface” is only materially different for this purpose if some
functionality is removed; thus saying that it’s simplified isn’t enough to
establish that it contains different information or functionality.*

In my experience, I've rarely found a mobile menu that works before
remediation.

This is one issue I would like to ensure is addressed in WCAG 2.1, without
a loophole, which is why I say "changed menu mechanism". Perhaps there is a
more precise way to define a mobile menu without actually saying it... I
guess an inaccessible mobile menu has some functionality removed. Here is a
specific list of common failures

-hamburger menu doesn't get focus
-Menu links don't follow the button, but are visually via css from the
bottom of the page
-Can't access sub menu items
-Expanded collapsed state not announced
etc...

...

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 Tue, Jun 28, 2016 at 5:00 PM, David MacDonald <david100@sympatico.ca>
wrote:

> As per Patricks suggestions in the WIKI, I've changed the proposal in not
> 8 to the following:
>
>    Note 8: Views or layouts other than those delivered based on screen
> size, device type, user agent, etc can be considered "alternatives" ONLY IF
> they satisfy the fundamental requirement laid out in items 1, 2, 3, 4 of
> this definition (i.e., a view with a changed menu mechanism, more or less
> content, or a simplified interface, would have different functionality from
> the view that was delivered to the user agent and therefore not qualify
> under item 2 of this definition)
>
> https://www.w3.org/WAI/GL/wiki/WCAG_Conformance_Criteria_4
>
> 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 Tue, Jun 28, 2016 at 4:24 PM, David MacDonald <david100@sympatico.ca>
> wrote:
>
>> I've put up a proposal to add Note 8 to the definition of Conforming
>> Alternative Version. I think Jason had it right when he said the small and
>> large screen versions that have different menus, less content, etc... don't
>> have the same functionality. I don't think we have to "change" WCAG if that
>> is true. The proposed note formalizes that.
>>
>> ​       ​
>> Note 8: If pages that are optimized for small screen have different
>> functionality from pages optimized for large screen, such as a changed menu
>> mechanism, or less content, or simplified interface, etc. the two views do
>> not have the same functionality and therefore cannot be used as conforming
>> alternatives for each other.
>>
>> https://www.w3.org/WAI/GL/wiki/WCAG_Conformance_Criteria_4
>>
>> This simple note solves the issue for me. I'm wondering what other think.
>>
>> 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 Tue, Jun 28, 2016 at 3:43 PM, David MacDonald <david100@sympatico.ca>
>> wrote:
>>
>>> Patrick says:
>>> >"If a site provides different views/layouts depending on factors
>>> outside of the user's control, such as screen size, device type, user
>>> agent, etc, each of these views/layouts needs to be accessible, or
>>> offer a mechanism to switch to an accessible alternative version (as
>>> per https://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef)"
>>>
>>> I think I gave two viable examples.
>>> 1) Low vision users who use a screen reader will have a degraded
>>> experience (see below for more details).
>>> 2) Blind users will have an unnecessarily cluttered experience for
>>> example trying to use VO on iOS to navigate a mega menu for desktop, and
>>> swiping through hundreds of link and having to rotate their rotor for every
>>> new type of element they want to find
>>>
>>> There may be other scenarios such as Alan raised, but to me these two
>>> are enough...
>>>
>>> When I say "People with disabilities deserve better", I am certainly
>>> saying just that. I'm not saying anyone else doesn't care about people with
>>> disabilities. I have no idea what is in someone else's head. But I will say
>>> that it is objectively a worse experience experience to try to use a
>>> desktop site on a mobile device. Otherwise Corporations would not spend
>>> $200,000 to develop their "small screen" strategy. Why would we want to
>>> create that kind of a hole in WCAG 2.1?
>>>
>>> >>> Sadly, I also have to remind us that legally accessible and
>>> "awesome user experience" are not equal, and while I will advocate for
>>> "awesome user experience" 8 days a week, we also need to be cognizant of
>>> the difference between legally "accessible" and awesome user experience. We
>>> should not and (IMHO cannot) use WCAG as some form of bully stick to force
>>> site owners to do things that certainly improve the UX for all users, but
>>> are not explicitly real barriers to PwD.
>>>
>>> I think I have to remind us that we are opening up WCAG to clean up
>>> accessibility problems. We should not be settling on legal loopholes that
>>> force people with disabilities to use a complicated clunky "large
>>> screen" interface on their mobile device.
>>>
>>> John says.
>>> >>I've offered/asked David to return with positively phrased language
>>> for the WG to contemplate.
>>>
>>> Success Criteria don't have negative action words telling the author
>>> what to do, like "don't", "should not", "Avoid" etc. However, in some
>>> Success Criteria, the elements of the content "do not" have certain
>>> characteristics. (See 1.3.3, 2.3.1, 2.3.2, 4.1.1)
>>>
>>> Conformance Requirements have negative statements.
>>> ​ In face most of them do. Here are some examples.​
>>>
>>>
>>> ​-​
>>> Conformance Req #2 "... cannot be achieved if part of a Web page is
>>> excluded."
>>> ​-​
>>> Conformance Req #3 "...Conformance is not possible at a particular level
>>> if any page in the process does not conform at that level or better."
>>> ​-​
>>> Conformance Req#5 "...Then they do not block the ability of users to
>>> access the rest of the page. "
>>>
>>> ​Patrick says:
>>> >>And that would be caught by appropriate SCs from the Low Vision TF,
>>>
>>> They are in the gap analysis and they won't have SC proposals until
>>> DEC/NOV.  Waiting that long to clean up the conformance section will be
>>> precarious because everything will be locking in.
>>>
>>> Looking over their document, I don't see this issue plugged sufficiently
>>> for blind users and am not sure that it is plugged for low vision users
>>> either. There are no requirements on authors set out yet.
>>>
>>> >and for a blind person...what, specifically (providing that the
>>> desktop version is accessible)?​
>>> I think I gave two examples above.
>>>
>>> >John asks for a specific proposal:
>>>
>>> I think Jason had the fundamental question right. The small screen view
>>> has a different functionality from the large screen view, so I'm
>>> suggestiing we add a note 8  to the definitkon o Conforming alternative.
>>>
>>> conforming alternate version
>>>
>>>    1.
>>>
>>>    conforms at the designated level, and
>>>    2.
>>>
>>>    provides all of the same information and functionality
>>>    <https://www.w3.org/TR/WCAG20/#functiondef> in the same human
>>>    language <https://www.w3.org/TR/WCAG20/#human-langdef>, and
>>>
>>> *...*
>>>
>>> *<add> Note 8: *If pages that are optimized for small screen have
>>> different functionality from pages optimized for large screen, such as a
>>> changed menu mechanism, or less content, or simplified interface, etc. the
>>> two views do not have the same functionality and therefore cannot be used
>>> as conforming alternatives for each other.</add>
>>>
>>>
>>>
>>> >>
>>>
>>> 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 Tue, Jun 28, 2016 at 2:47 PM, John Foliot <john.foliot@deque.com>
>>> wrote:
>>>
>>>> > Why is there a Mobile Task force if we allow a simple link to bypass
>>>> the entire requirements that we are formulating?
>>>>
>>>> David, where is it saying that? *IF* providing a link to the desktop
>>>> version makes the mobile experience *more* accessible, then it should not
>>>> be rejected out of hand. If the desktop solution doesn't also meet the
>>>> (new) SC we bring forward targeted towards (mobile) smaller screens, then
>>>> it doesn't meet the requirement, and so linking to the "desktop" version
>>>> does not address the issues and does not change the conformance statement.
>>>>
>>>> This also illustrates why I push back on using the Success and Failure
>>>> Techniques as the definitive way of tracking conformance: state the
>>>> requirements clearly, and leave open the possibility that a whole new
>>>> technique meets the functional requirements of the Success Criteria. In
>>>> other words, judge on the outcomes, and stop trying to impose specific
>>>> patterns.
>>>>
>>>> JF
>>>>
>>>> On Tue, Jun 28, 2016 at 1:21 PM, David MacDonald <david100@sympatico.ca
>>>> > wrote:
>>>>
>>>>> I think if we get so theoretical about the web that we can't even say
>>>>> the word "Mobile", even in our internal discussions then we risk living in
>>>>> an academic bubble.
>>>>>
>>>>> Why is there a Mobile Task force if we allow a simple link to bypass
>>>>> the entire requirements that we are formulating? This is not "melodramatic
>>>>> rhetoric" in my mind it is a very real question. It's like buying a $400
>>>>> lock for your front door, and leaving the back door open and the light on.
>>>>>
>>>>> I think anyone who has been around for a long time knows that I don't
>>>>> mind loosing an argument I wrong about. I concede more often than I press
>>>>> in.  But honestly, I feel this is a crazy discussion, about not requiring
>>>>> ANY mobile view to follow ANY WCAG SCs, given that we ripped open WCAG 2 to
>>>>> update it to the modern web.
>>>>>
>>>>> 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 Tue, Jun 28, 2016 at 1:44 PM, ALAN SMITH <alands289@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Patrick,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, the distinction of “mobile” has always been hard to define, even
>>>>>> when we were starting out with the Mobile Accessibility Task Force, I had
>>>>>> question does this also mean tablets, tablets with keyboards, 10inch
>>>>>> screens, etc.
>>>>>>
>>>>>> Are my tablets only mobile devices if I have cellular service and
>>>>>> when I sit down in my house and use wifi are they no longer “mobile”
>>>>>> devices?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Companies are creating “mobile” or “tablet” or “small glass/medium
>>>>>> glass” apps. If we consider them as
>>>>>>
>>>>>> you state “instead qualify it more specifically as being "touchscreen
>>>>>> accessibility", "small-screen
>>>>>>
>>>>>> accessibility", we find the same issues. These smaller screens often
>>>>>> have totally different user interface and content design with a lot less
>>>>>> clutter.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So I think my premise of the differences with “desktop” (which can be
>>>>>> touch also) designed web and smaller screen native apps and web still is
>>>>>> valid.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alan Smith, CSTE, CQA
>>>>>>
>>>>>> Sent from Mail for Windows 10
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Patrick H. Lauke <redux@splintered.co.uk>
>>>>>> *Sent: *Tuesday, June 28, 2016 1:19 PM
>>>>>> *To: *WCAG <w3c-wai-gl@w3.org>; public-mobile-a11y-tf@w3.org
>>>>>> *Subject: *Re: Conforming alternative for mobile should not be
>>>>>> Desktop
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 28/06/2016 18:05, ALAN SMITH wrote:
>>>>>>
>>>>>> > +1 with David’s comment.
>>>>>>
>>>>>> >
>>>>>>
>>>>>> > It says to me “mobile accessibility is not needed”.
>>>>>>
>>>>>> >
>>>>>>
>>>>>> > I had the same thoughts of this indicating we can scrap all the
>>>>>> work of
>>>>>>
>>>>>> > the Mobile Accessibility task force.
>>>>>>
>>>>>>
>>>>>>
>>>>>> One of the main problems I see with this whole rhetoric is: you're
>>>>>> still
>>>>>>
>>>>>> talking about "mobile vs desktop" as if those were two nicely
>>>>>> separate,
>>>>>>
>>>>>> distinct silos. They're not. We need to move away from treating
>>>>>>
>>>>>> something as "mobile accessibility" and instead qualify it more
>>>>>>
>>>>>> specifically as being "touchscreen accessibility", "small-screen
>>>>>>
>>>>>> accessibility", etc. Already there are plenty of device in the market
>>>>>>
>>>>>> today (such as 2-in-1 laptops) which blur the line, but still require
>>>>>>
>>>>>> SCs and Guidelines that apply to new input/display/etc methods
>>>>>> available.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>
>>>
>>>
>>
>