- From: John Foliot <john.foliot@deque.com>
- Date: Tue, 28 Jun 2016 08:51:52 -0500
- To: David MacDonald <david100@sympatico.ca>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <CAKdCpxxQGQBcSNAy8U6Pc+drCtsr0Vqoj-to8oCc0VcZS-PF_A@mail.gmail.com>
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
Received on Tuesday, 28 June 2016 13:52:23 UTC