- From: David MacDonald <david100@sympatico.ca>
- Date: Tue, 28 Jun 2016 17:09:09 -0400
- To: John Foliot <john.foliot@deque.com>
- CC: ALAN SMITH <alands289@gmail.com>, "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: <BLU436-SMTP2210A2ED09972DE3499C352FE220@phx.gbl>
*For example, what does a “different menu mechanism” mean? A “simplified interface” is only materially different for this purpose if some functionality is removed; thus saying that it’s simplified isn’t enough to establish that it contains different information or functionality.* In my experience, I've rarely found a mobile menu that works before remediation. This is one issue I would like to ensure is addressed in WCAG 2.1, without a loophole, which is why I say "changed menu mechanism". Perhaps there is a more precise way to define a mobile menu without actually saying it... I guess an inaccessible mobile menu has some functionality removed. Here is a specific list of common failures -hamburger menu doesn't get focus -Menu links don't follow the button, but are visually via css from the bottom of the page -Can't access sub menu items -Expanded collapsed state not announced etc... ... 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 5:00 PM, David MacDonald <david100@sympatico.ca> wrote: > As per Patricks suggestions in the WIKI, I've changed the proposal in not > 8 to the following: > > Note 8: Views or layouts other than those delivered based on screen > size, device type, user agent, etc can be considered "alternatives" ONLY IF > they satisfy the fundamental requirement laid out in items 1, 2, 3, 4 of > this definition (i.e., a view with a changed menu mechanism, more or less > content, or a simplified interface, would have different functionality from > the view that was delivered to the user agent and therefore not qualify > under item 2 of this definition) > > https://www.w3.org/WAI/GL/wiki/WCAG_Conformance_Criteria_4 > > 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 4:24 PM, David MacDonald <david100@sympatico.ca> > wrote: > >> I've put up a proposal to add Note 8 to the definition of Conforming >> Alternative Version. I think Jason had it right when he said the small and >> large screen versions that have different menus, less content, etc... don't >> have the same functionality. I don't think we have to "change" WCAG if that >> is true. The proposed note formalizes that. >> >> >> Note 8: If pages that are optimized for small screen have different >> functionality from pages optimized for large screen, such as a changed menu >> mechanism, or less content, or simplified interface, etc. the two views do >> not have the same functionality and therefore cannot be used as conforming >> alternatives for each other. >> >> https://www.w3.org/WAI/GL/wiki/WCAG_Conformance_Criteria_4 >> >> This simple note solves the issue for me. I'm wondering what other think. >> >> 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 3:43 PM, David MacDonald <david100@sympatico.ca> >> wrote: >> >>> Patrick says: >>> >"If a site provides different views/layouts depending on factors >>> outside of the user's control, such as screen size, device type, user >>> agent, etc, each of these views/layouts needs to be accessible, or >>> offer a mechanism to switch to an accessible alternative version (as >>> per https://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef)" >>> >>> I think I gave two viable examples. >>> 1) Low vision users who use a screen reader will have a degraded >>> experience (see below for more details). >>> 2) Blind users will have an unnecessarily cluttered experience for >>> example trying to use VO on iOS to navigate a mega menu for desktop, and >>> swiping through hundreds of link and having to rotate their rotor for every >>> new type of element they want to find >>> >>> There may be other scenarios such as Alan raised, but to me these two >>> are enough... >>> >>> When I say "People with disabilities deserve better", I am certainly >>> saying just that. I'm not saying anyone else doesn't care about people with >>> disabilities. I have no idea what is in someone else's head. But I will say >>> that it is objectively a worse experience experience to try to use a >>> desktop site on a mobile device. Otherwise Corporations would not spend >>> $200,000 to develop their "small screen" strategy. Why would we want to >>> create that kind of a hole in WCAG 2.1? >>> >>> >>> Sadly, I also have to remind us that legally accessible and >>> "awesome user experience" are not equal, and while I will advocate for >>> "awesome user experience" 8 days a week, we also need to be cognizant of >>> the difference between legally "accessible" and awesome user experience. We >>> should not and (IMHO cannot) use WCAG as some form of bully stick to force >>> site owners to do things that certainly improve the UX for all users, but >>> are not explicitly real barriers to PwD. >>> >>> I think I have to remind us that we are opening up WCAG to clean up >>> accessibility problems. We should not be settling on legal loopholes that >>> force people with disabilities to use a complicated clunky "large >>> screen" interface on their mobile device. >>> >>> John says. >>> >>I've offered/asked David to return with positively phrased language >>> for the WG to contemplate. >>> >>> Success Criteria don't have negative action words telling the author >>> what to do, like "don't", "should not", "Avoid" etc. However, in some >>> Success Criteria, the elements of the content "do not" have certain >>> characteristics. (See 1.3.3, 2.3.1, 2.3.2, 4.1.1) >>> >>> Conformance Requirements have negative statements. >>> In face most of them do. Here are some examples. >>> >>> >>> - >>> Conformance Req #2 "... cannot be achieved if part of a Web page is >>> excluded." >>> - >>> Conformance Req #3 "...Conformance is not possible at a particular level >>> if any page in the process does not conform at that level or better." >>> - >>> Conformance Req#5 "...Then they do not block the ability of users to >>> access the rest of the page. " >>> >>> Patrick says: >>> >>And that would be caught by appropriate SCs from the Low Vision TF, >>> >>> They are in the gap analysis and they won't have SC proposals until >>> DEC/NOV. Waiting that long to clean up the conformance section will be >>> precarious because everything will be locking in. >>> >>> Looking over their document, I don't see this issue plugged sufficiently >>> for blind users and am not sure that it is plugged for low vision users >>> either. There are no requirements on authors set out yet. >>> >>> >and for a blind person...what, specifically (providing that the >>> desktop version is accessible)? >>> I think I gave two examples above. >>> >>> >John asks for a specific proposal: >>> >>> I think Jason had the fundamental question right. The small screen view >>> has a different functionality from the large screen view, so I'm >>> suggestiing we add a note 8 to the definitkon o Conforming alternative. >>> >>> conforming alternate version >>> >>> 1. >>> >>> conforms at the designated level, and >>> 2. >>> >>> provides all of the same information and functionality >>> <https://www.w3.org/TR/WCAG20/#functiondef> in the same human >>> language <https://www.w3.org/TR/WCAG20/#human-langdef>, and >>> >>> *...* >>> >>> *<add> Note 8: *If pages that are optimized for small screen have >>> different functionality from pages optimized for large screen, such as a >>> changed menu mechanism, or less content, or simplified interface, etc. the >>> two views do not have the same functionality and therefore cannot be used >>> as conforming alternatives for each other.</add> >>> >>> >>> >>> >> >>> >>> 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 2:47 PM, John Foliot <john.foliot@deque.com> >>> wrote: >>> >>>> > Why is there a Mobile Task force if we allow a simple link to bypass >>>> the entire requirements that we are formulating? >>>> >>>> David, where is it saying that? *IF* providing a link to the desktop >>>> version makes the mobile experience *more* accessible, then it should not >>>> be rejected out of hand. If the desktop solution doesn't also meet the >>>> (new) SC we bring forward targeted towards (mobile) smaller screens, then >>>> it doesn't meet the requirement, and so linking to the "desktop" version >>>> does not address the issues and does not change the conformance statement. >>>> >>>> This also illustrates why I push back on using the Success and Failure >>>> Techniques as the definitive way of tracking conformance: state the >>>> requirements clearly, and leave open the possibility that a whole new >>>> technique meets the functional requirements of the Success Criteria. In >>>> other words, judge on the outcomes, and stop trying to impose specific >>>> patterns. >>>> >>>> JF >>>> >>>> On Tue, Jun 28, 2016 at 1:21 PM, David MacDonald <david100@sympatico.ca >>>> > wrote: >>>> >>>>> I think if we get so theoretical about the web that we can't even say >>>>> the word "Mobile", even in our internal discussions then we risk living in >>>>> an academic bubble. >>>>> >>>>> Why is there a Mobile Task force if we allow a simple link to bypass >>>>> the entire requirements that we are formulating? This is not "melodramatic >>>>> rhetoric" in my mind it is a very real question. It's like buying a $400 >>>>> lock for your front door, and leaving the back door open and the light on. >>>>> >>>>> I think anyone who has been around for a long time knows that I don't >>>>> mind loosing an argument I wrong about. I concede more often than I press >>>>> in. But honestly, I feel this is a crazy discussion, about not requiring >>>>> ANY mobile view to follow ANY WCAG SCs, given that we ripped open WCAG 2 to >>>>> update it to the modern web. >>>>> >>>>> 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 1:44 PM, ALAN SMITH <alands289@gmail.com> >>>>> wrote: >>>>> >>>>>> Patrick, >>>>>> >>>>>> >>>>>> >>>>>> Yes, the distinction of “mobile” has always been hard to define, even >>>>>> when we were starting out with the Mobile Accessibility Task Force, I had >>>>>> question does this also mean tablets, tablets with keyboards, 10inch >>>>>> screens, etc. >>>>>> >>>>>> Are my tablets only mobile devices if I have cellular service and >>>>>> when I sit down in my house and use wifi are they no longer “mobile” >>>>>> devices? >>>>>> >>>>>> >>>>>> >>>>>> Companies are creating “mobile” or “tablet” or “small glass/medium >>>>>> glass” apps. If we consider them as >>>>>> >>>>>> you state “instead qualify it more specifically as being "touchscreen >>>>>> accessibility", "small-screen >>>>>> >>>>>> accessibility", we find the same issues. These smaller screens often >>>>>> have totally different user interface and content design with a lot less >>>>>> clutter. >>>>>> >>>>>> >>>>>> >>>>>> So I think my premise of the differences with “desktop” (which can be >>>>>> touch also) designed web and smaller screen native apps and web still is >>>>>> valid. >>>>>> >>>>>> >>>>>> >>>>>> Alan Smith, CSTE, CQA >>>>>> >>>>>> Sent from Mail for Windows 10 >>>>>> >>>>>> >>>>>> >>>>>> *From: *Patrick H. Lauke <redux@splintered.co.uk> >>>>>> *Sent: *Tuesday, June 28, 2016 1:19 PM >>>>>> *To: *WCAG <w3c-wai-gl@w3.org>; public-mobile-a11y-tf@w3.org >>>>>> *Subject: *Re: Conforming alternative for mobile should not be >>>>>> Desktop >>>>>> >>>>>> >>>>>> >>>>>> On 28/06/2016 18:05, ALAN SMITH wrote: >>>>>> >>>>>> > +1 with David’s comment. >>>>>> >>>>>> > >>>>>> >>>>>> > It says to me “mobile accessibility is not needed”. >>>>>> >>>>>> > >>>>>> >>>>>> > I had the same thoughts of this indicating we can scrap all the >>>>>> work of >>>>>> >>>>>> > the Mobile Accessibility task force. >>>>>> >>>>>> >>>>>> >>>>>> One of the main problems I see with this whole rhetoric is: you're >>>>>> still >>>>>> >>>>>> talking about "mobile vs desktop" as if those were two nicely >>>>>> separate, >>>>>> >>>>>> distinct silos. They're not. We need to move away from treating >>>>>> >>>>>> something as "mobile accessibility" and instead qualify it more >>>>>> >>>>>> specifically as being "touchscreen accessibility", "small-screen >>>>>> >>>>>> accessibility", etc. Already there are plenty of device in the market >>>>>> >>>>>> today (such as 2-in-1 laptops) which blur the line, but still require >>>>>> >>>>>> SCs and Guidelines that apply to new input/display/etc methods >>>>>> available. >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>> >>> >>> >> >
Received on Tuesday, 28 June 2016 21:09:52 UTC