Re: Conforming alternative for mobile should not be Desktop

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
>