Re: Conforming alternative for mobile should not be Desktop

David wrote:

> My  suggestion is simply to add a line to the understanding doc on
conforming alternative that says something like "...same functionality
includes functions optimized for screen size. Therefore functions optimized
for large screen cannot be used as a conforming alternative for functions
optimized for small screen"

A reminder that the Understanding document(s) are non-normative, and so any
directives there are, at best, hints or suggestions. And I would be
extremely hesitant to state something like, because we have no idea whether
that would be true or not in any given circumstance. I'd also remind everyone
that David's article on how to write good Success Criteria stated that SC:


   1. Describe the affirmative condition of the passing content
   2. Success Criteria are technology neutral

...and so a negative statement like that, "...functions optimized for large
screen cannot be used..." is inappropriate in Success Criteria language
because screen size is technology specific, and the term 'cannot' is not an
affirmative statement.


> not forcing blind people to go home and use their desktops because the
mobile view doesn't work.

David, can you provide us with an example of this use-case? I would like to
understand how a change in viewport size would affect a blind person.

I'd also like to see how HTML code and the HTML-native and ARIA-based calls
to the Accessibility APIs are being impacted by screen size, and/or the
editorial impact that is caused in responsive design when a screen is in
"mobile" view.

Currently, the only significant issue I am aware of is when CSS FlexBox is
deployed as part of the design, at which point the re-ordering that is
being done on screen may have an impact, but that impact is primarily a
visual one, where content is being re-arranged on screen but the DOM order
remains unchanged, resulting in illogical tab-key navigation. The APA is
currently in discussions with the CSS WG about this, and/but it remains a
vexing issue.

The other issues that I am aware of, currently in another active thread, is
locking the orientation of the viewport, and locking reflow/text zoom, but
both of those issues aren't really impactful on Blind users, although they
are on low-vision, mobility impaired, and one could argue cognitively
impaired users.

As well, what of sites that are NOT responsive? Sites that are 'optimised'
for a desktop, and/but that view is also what is served up to tablets and
cell phones? Are you suggesting that we fail content authors for not
creating responsive designs today? (I don't think so, but want to check any
assumptions early.) David referenced the definition of *conforming
alternative* in WCAG 2.0 (
https://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef), and I will
point out the following as well:

*Note 4: *Alternate versions may be provided to accommodate different
technology environments or user groups. Each version should be as
conformant as possible. One version would need to be fully conformant in
order to meet conformance requirement 1
<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#cc1>.


I suspect that this is one of the roots of David's concerns, but I do not
know how to re-work this wording for WCAG 2.1 without breaking backward
compatibility with 2.0, outside of creating a specific new Success Criteria
that addresses content in a viewport based on size (which feels extremely
prescriptive and technology dependent).

JF

On Tue, Jun 28, 2016 at 8:13 AM, David MacDonald <david100@sympatico.ca>
wrote:

> I think we can do whatever we need to do to ensure the web is accessible.
> We have a mandate in the charter to ensure mobile is accessible. That's why
> we are all donating months of our lives to the Mobile Task Force.
>
>  If there is a huge hole in WCAG 2.1 that says, "Hey we have a bunch of
> new SCs to meet for mobile, but you don't need to do any of this because
> the conforming alternative clause allows you to rely on the large screen
> view" then what is the point?
>
> We certainly can, and should plug this hole if we think it's important.
>
> If you are thinking of a more global statement about conforming
> alternatives then feel free to suggest one. My  suggestion is simply to add
> a line to the understanding doc on conforming alternative that says
> something like "...same functionality includes functions optimized for
> screen size. Therefore functions optimized for large screen cannot be used
> as a conforming alternative for functions optimized for small screen"
>
> I know it's not perfect but its a start and we can fix the wording to
> accomplish our goal the not forcing blind people to go home and use their
> desktops because the mobile view doesn't work.
>
> 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 8:45 AM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> I (cautiously) agree with the sentiment expressed here (and the fact that
>> you used "large screen" vs "small screen" wording). However, it could be
>> argued that as long there's a link or similar mechanism to go from the
>> (inaccessible) mobile view to the (accessible) desktop view - which IS
>> required as per point 4 of the definition - then it's fine in the same way
>> that having two alternatives purely on desktop is fine? Considering that
>> the "desktop" view will be accessible on the phone/tablet (but will likely
>> be less *usable* due to the for the user to zoom/scroll horizontally/etc)?
>>
>> i.e. I don't see how a special case can be made to plug the gap only in
>> the specific mobile/desktop situation.
>>
>> P
>>
>>
>> On 28/06/2016 13:29, David MacDonald wrote:
>>
>>> We currently have a bit of a hole in WCAG 2 that I think we should plug
>>> in 2.1.
>>>
>>> If a web page has a conforming alternative, then it doesn't need to
>>> conform itself. However, in the world of responsible design, it means if
>>> the desktop version conforms, the mobile version does not need to. I
>>> think we should plug this in WCAG 2.1.
>>>
>>> It might be as  simple as adding a sentence to the definition of
>>> conforming alternative that large screen views of web pages do not
>>> qualify as a conforming alternative to small screen views. It will take
>>> some thought as to the exact wording and approach but it needs to be
>>> addressed I woulds say, otherwise organizations may just say they don't
>>> meed to make the mobile view accessible.
>>>
>>> https://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef
>>>
>>>
>>> Cheers,
>>> David MacDonald
>>>
>>>
>>>
>>> *Can**Adapt**Solutions Inc.*
>>>
>>> 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>
>>>
>>
>>
>> --
>> 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