Re: Conforming alternative for mobile should not be Desktop

>OLD current) Section 508 the Alternate accessible version requirement identified that it should be right at the top of the page

I have not seen such language in the Section 508 standard.     But it does say that an alternative can only be used if the regular content cannot reasonable be made accessible.    WCAG does not have such as requirement.

Jon

Sent from my iPhone

On Jun 28, 2016, at 1:38 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com<mailto:ryladog@gmail.com>> wrote:

I think one issue affecting this is that in (OLD current) Section 508 the Alternate accessible version requirement identified that it should be right at the top of the page, first thing, so that if a user needed to switch out to get to it, they must be  able to access it immediately and accessibly…..:-)

​​​​​



* katie *

Katie Haritos-Shea
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | ryladog@gmail.com<mailto:ryladog@gmail.com> | Oakton, VA | LinkedIn Profile<http://www.linkedin.com/in/katieharitosshea/> | Office: 703-371-5545 | @ryladog<https://twitter.com/Ryladog>

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Tuesday, June 28, 2016 1:27 PM
To: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>
Cc: Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>
Subject: Re: Conforming alternative for mobile should not be Desktop

Hi David,

> I don't think sticking a link to a desktop site at the bottom of the mobile view is the spirit of the alternate version provision as we created it.

Why not, and can you point to past discussions that would back up the claim that the thinking was for "more"? By your own admission, this arose from the earlier WCAG 1.0 Requirement "...the old alternative text version provision in WCAG 1.1. We didn't want to forbid people from making an alternative like that if it was kept up to date and had all the information." (I don't see anything about "experience" there BTW)


> a hugely degraded experience for a low vision user and also a blind person

Strong claim, but where is the proof? 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 do not want to tell my clients, in age where we fly to mars, "don't worry about mobile accessibility, just put a link to the desktop version in all your responsive designs."

Nobody but David MacDonald has said that David, and I don't think that comment, or the one about packing up the Mobile TF, are very helpful (it instead comes off like a temper tantrum). You have not provided any specifics, no examples of where this is truly an accessibility problem (versus a usability / UX problem that impacts more than just PwD), but instead it comes off as a blanket statement that wants to be extremely prescriptive in what site/content owners MUST do - you are straying from Principles to specifics, and I will suggest that that isn't really in the spirit of the Web Content Accessibility >>GUIDELINES<<.

Look, we've set up the Mobile TF to look at, and propose new Success Criteria for WCAG 2.1, and I agree with what Patrick said:

"If a site, when viewed on a mobile/tablet/small screen viewport is inaccessible, and it does NOT provide a mechanism for the user to reach (on that same device/viewport) the accessible "desktop" version, then it fails under WCAG 2.0 (for all the bits where it's inaccessible), and can't claim to be an "alternate version" as, per point 4 of the definition"

I'll further add that if the mobile site offers a desktop "alternative", and that alternative isn't any more accessible to PwD on a mobile device (where that link to the desktop version is asserting that it is the functional requirement for that claim), then they've not met the requirement of the definition, and specifically #2: provides all of the same information and functionality<https://www.w3.org/TR/WCAG20/#functiondef> - so it fails.

David, I'm confused. You write to the WCAG WG reminding us that SC need to be positively worded statements, and then you start a thread that is about setting a negative condition: specifically "Conforming alternative for mobile should not be Desktop". I think that as a start, perhaps returning to the idea of setting this out as a positive statement would be helpful, and that a clear indication of the *barrier* (and poor UX really isn't a barrier to PwD any more than it is to everyone) that is being addressed. Looking to get some insistive MUST-like language into WCAG to force a client to do something is not what WCAG is for.

JF


On Tue, Jun 28, 2016 at 11:53 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
I don't agree ...

I don't think sticking a link to a desktop site at the bottom of the mobile view is the spirit of the alternate version provision as we created it.

This is a hugely degraded experience for a low vision user and also a blind person who is going to be accessing a desktop site in a mobile browser ... this is not at all what we intended with the alternate version exemption.

The alternate version exemption came from the old alternative text version provision in WCAG 1.1. We didn't want to forbid people from making an alternative like that if it was kept up to date and had all the information.

WCAG 2.1 will be out in 2018. I do not want to tell my clients, in age where we fly to mars, "don't worry about mobile accessibility, just put a link to the desktop version in all your responsive designs."

If we do that, let's just close up the Mobile task force now and not waste our time. People with disabilities deserve better.



Cheers,
David MacDonald



CanAdapt Solutions Inc.
Tel:  613.235.4902<tel:613.235.4902>

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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 11:04 AM, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:
Hi Patrick,

I think we are agreeing.

JF

On Tue, Jun 28, 2016 at 9:09 AM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 28/06/2016 14:13, David MacDonald wrote:
not forcing blind people to go home and use
their desktops because the mobile view doesn't work.

To be absolutely clear on where I'm coming from:  IF a site, when viewed on a mobile/tablet/small screen viewport is inaccessible, and it does NOT provide a mechanism for the user to reach (on that same device/viewport) the accessible "desktop" version, then it fails under WCAG 2.0 (for all the bits where it's inaccessible), and can't claim to be an "alternate version" as, per point 4 of the definition, it's not allowing the user to reach the desktop version.

This is why I don't think specifically calling out "the mobile version/view needs to be accessible" is needed, and it feels wrong/weird to single it out.

P

--
Patrick H. Lauke

www.splintered.co.uk<http://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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion




--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion