Re: Conforming alternative for mobile should not be Desktop

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