Re: Conforming alternative for mobile should not be Desktop

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