a degraded experience (was Re: Conforming alternative for mobile should not be Desktop)

Hi David,

I don't think anyone on this list would disagree that a degraded experience
is not what we should be seeking as an end-state. The reality is however
that we don't always get perfect, and sometimes not even good: instead
sometimes we will get "meets minimum functional requirements", and while
that sucks from a UX perspective, it does meet the letter of the law (where
the law is a direct reading of WCAG 2.0 by lawyers, and not UX specialists).

I share the frustration that this interpretation brings, but I also want to
be very clear: anything we do that tries to impose a specific pattern, or
that seeks to change the status quo of WCAG 2.0 from what it is today will
be met with resistance - certainly from me - because we are now approaching
a situation of applying Undue Burden on content owners, who will use *that*
clause to do nothing, and the overall net result will be even worse than
"good enough".

Your concern, and use-case, certainly reflects an inferior user experience
for users of certain types of Assistive Technology, and I share the dismay,
but we cannot say that the degraded experience *isn't* accessible if in
fact it is, albeit "clunky" or frustrating. Those frustrations are just as
likely to be experienced by users who do not have a specific disability -
it's a UX problem then, not a WCAG problem.

WCAG is not, and can not be (IMHO) some kind of bully stick to force
authors to do more than what is required by the specification (and laws
based on the specification) - that is where our advocacy and education
efforts come to play. You're right: asking a wheelchair user to enter the
restaurant via the back door and through the kitchen is hardly a welcoming
gesture, and smart businesses would recognize that as such early on.

But what of a restaurant that is located in a heritage building or similar
situation that cannot be modified in any way to allow that end-user to
enter through the front door? (perhaps the 4 foot thick stone walls make
enlarging the width of the front door for a wheelchair impossible?) Tell
them to close the restaurant or move? Hardly, and so for that use-case,
entering via the kitchen, while not very glamorous, does provide the
accommodation required *by law*. That may not be what we want to hear, but
that is the reality today.

>
​
The hamburger is served up specifically for the mobile view. If it doesn't
work with VO or TB,

...then it Fails, and quite possibly because of reasons already covered in
WCAG  2.0 (or, moving forward, through 'holes' plugged in WCAG 2.1)

> the person with the disability is forced to go chasing after some other
version, which is not designed for mobile bandwidth, for small screen, for
operation on the go, etc... it is a degraded experience.

Correct, but "degraded experience" is not against any laws that I know of
around accessibility, with perhaps the exception of ACAA (Aircraft Carriers
Accessibility Act), which also requires a level of usability testing as
well (although what is usable for one may not be usable for another, and so
that is and will remain a subjective determination, hard to defend in a
court of law).

>
​
You feel that our users should be content finding a desktop link navigating
to it and using it on a mobile phone.

I don't think anyone is "content" with that option David, and please be
careful when attributing any motive or personal justification to others in
the WG - claiming a moral high-ground and suggesting that others are not up
to that standard is not helpful in the long run.

I think instead some of us recognize that while it may be an extremely poor
usability experience, it *does* meet the minimum bar for legally acceptable
2.0 conformance, *if* the link to the alternative site (aka Desktop) is, a)
fully WCAG 2.0 compliant, and b) delivers all of the *same functionality*
to the end users regardless of screen-size/device. If either of those
conditions are not true, then the site can not claim conformance to WCAG
2.0 - and that is the case even today by my reading of WCAG.

As we move forward with WCAG 2.1, and *when* clients either adopt 2.1 as
their standard, or legislators make 2.1 the minimum requirement, *THEN* you
will have more of a legal leg to stand on, but that is not because of WCAG
2.1, it will because the laws have changed. Meanwhile, strong advocacy and
education will be required to bridge any gaps between minimally compliant,
and a delightful and joyous user experience.

>
​
If the site follows the new SCs, there is no requirement to get the mobile
menu right,...

David, there is no evidence that this will be the case: we don't even have
all of the SC in hand yet, so how does anyone know whether or not they "get
the mobile menu right" when we don't even have a WCAG definition of what
"right" is (or should be), and so I respectfully suggest you are jumping
way ahead of where we are today.

Your use-case is helpful when evaluating new SC, and we should strive to
ensure that all of the issues that you allude to in that use-case are met
with some kind of WCAG 2.1 SC, but I will again remind you that per the
current working time-line, WCAG 2.1 will only be looking to enter Rec
status in the summer of 2018, and any effort to retroactively change WCAG
2.0 today will be a show-stopper.

JF


On Wed, Jun 29, 2016 at 12:39 PM, David MacDonald <david100@sympatico.ca>
wrote:

> >>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?
>
> ​​
> The hamburger is served up specifically for the mobile view. If it doesn't
> work with VO or TB , the person with the disability is forced to go chasing
> after some other version, which is not designed for mobile bandwidth, for
> small screen, for operation on the go, etc... it is a degraded experience.
> I think it has everything to do with the discussion. In fact, it is my
> *primary* concern. If we solve this, I'll go back to my "real work".
>
> >>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).
>
> It is an objectively degraded experience to use a view optimized for
> desktop on a mobile site (and yes these are the current industry terms for
> these views) , plus the time it takes to find the desktop site.
>
> ​​
> Unless I'm misunderstanding something, we have a basic philosophical
> disagreement.
> ​​
> You feel that our users should be content finding a desktop link
> navigating to it and using it on a mobile phone.  I think the mobile menu,
> and widgets should work on a mobile device with the screen reader running.
>
> ​​
> If the site follows the new SCs, there is no requirement to get the mobile
> menu right, or any other part of the site specifically sent to the mobile
> view. Sure, the desktop conforms to WCAG, but it doesn't conform to common
> sense on a mobile device. Why should people with disabilities be forced in
> this back door when other users get the benefits of the mobile optimized
> site.
>
> This was not our intention for an accessible alternative as demonstrated
> in the the Understanding doc I sent.
>
>
>
> 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 12:53 PM, 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