Re: Conforming alternative for mobile should not be Desktop

Hi all,

I have to agree with Patrick here. If the goal is to try and apply some
type of retro-active SC requirement language to WCAG 2.0 to address known
and seen issues in the wild today, I start getting twitchy: any move that
makes sites that are compliant today to WCAG 2.0 (usability put aside for a
minute) non-compliant tomorrow is a deal-breaker, so for clarity sake, this
newly proposed language and 'conditions', while I agree are important, are
only applicable to sites claiming WCAG 2.1 conformance - correct?

If this is the case, then yes, we can strengthen the definition language by
modifying an existing 'point' (David's proposed Point 2 edit) or by adding
a new 'point' (the proposed Point 8 definition). However, as Patrick points
out, WCAG 2.1 will also include requirements that have emerged for
small-screen/touch devices that, when written well (platform agnostic) then
the requirements for a compliant WCAG 2.1 site will be applicable for both
of the 'views' we are discussing, whether optimised for large-screen or
small-screen use: in other words www.site.com and m.site.com will both need
be conformant to WCAG 2.1 when invoking that 'clause', so where is the
issue?

(Q: do we make as a conformance condition that in a use-case like this,
both"views" must meet the same conformance level? i.e. a "mobile" (sorry
Patrick) site that claims conformance to WCAG 2.1 by, in part, relying on
pointing to WCAG 2.0-only content, explicitly does NOT meet WCAG 2.1
conformance. Seems obvious, but should we document that somewhere?)

JF

On Wed, Jun 29, 2016 at 11:53 AM, 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