- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 27 Jun 2016 13:08:01 -0500
- To: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Cc: David MacDonald <david100@sympatico.ca>, "Patrick H. Lauke" <redux@splintered.co.uk>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <CAKdCpxzwGpRFUfs5NLyAfBy3ymZcyiWD9o0+n_j-=fmRKnVExg@mail.gmail.com>
Hi Gregg, Thanks for this. Curious to know your thoughts on Patrick's use-case. Would locking down the screen orientation or disabling zoom in your opinion be a Perceivable issue (1.x.x) or Robust issue (4.x.x)? Thanks. JF On Mon, Jun 27, 2016 at 12:42 PM, Gregg Vanderheiden < gregg@raisingthefloor.org> wrote: > yes > > user agent was intended to mean anything that would fetch information from > http:// and render to the user. > > *gregg* > > On Jun 27, 2016, at 1:02 PM, John Foliot <john.foliot@deque.com> wrote: > > David wrote: > > > WCAG Conformance Criteria 4 requires: > *4. Only Accessibility-Supported Ways of Using Technologies:* See Understanding > accessibility support > <http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head> > . > But that is about assistive technologies and special assisitive features > in browser. > > David, I'm going to push back just slightly on that. WCAG 2.0 currently > states: > Principle 4: Robust - Content must be robust enough that it can be > interpreted reliably by a wide variety of user agents, including assistive > technologies. > Guideline 4.1 Compatible: Maximize compatibility with current and future > user agents, including assistive technologies. > > In both of the above (principle and guideline) the specification > deliberately says "User agent" and not "browser", and so I believe we > need to be a little more open to the interpretation of user-agent. > In the use-case that Patrick brings up, locking down screen orientation > (and zoom) is something that the author can impact in the source code, even > though the code required is usually found in the <head> element as > meta-data and not the <body> element. So I disagree that this is a > Perceivable issue, it's a hardware (User Agent) issue impacted by user-code > (i.e. the device has been "locked" from auto-orientation/user-locked > orientation and/or zooming). Those features in the device(s) [aka user > agents] makes them Robust to the end user (end user can make changes to > meet their needs), and removing that ability impacts the Robustness of the > device(s). > > JF > > > > On Mon, Jun 27, 2016 at 10:07 AM, David MacDonald <david100@sympatico.ca> > wrote: > >> >>>An alternative would be to move the proposed guideline 3.4 under >> "Principle 1: Perceivable - Information and user interface components must >> be presentable to users in ways they can perceive.", and more explicitly >> under "Guideline 1.3 Adaptable: Create content that can be presented in >> different ways (for example simpler layout) without losing information or >> structure." - however, I feel this would cover only the >> visual/presentational aspect, rather than also any functional concerns >> (that content should also "work" in different orientations)...or perhaps >> I'm overthinking this part? >> >> You can never overthink an SC :-) ... They need to be kicked and >> prodded from every direction during development. I felt during the >> creation of WCAG 2 that Principle 4 was an area that was more difficult to >> develop, and didn't get as much attention as the other SCs. I think there >> is room to expand and fill it out in WCAG 2.1 if there is good reason to >> do so. >> >> I'm guessing that by "functional concerns" you mean that the content will >> still work in any orientation. I think you want to ensure in layman's >> terms "All content is in the horizontal aspect ratio of the viewport >> (Perceivable) and *works* in any orientation (Robust)". >> >> WCAG Conformance Criteria 4 requires: >> *4. Only Accessibility-Supported Ways of Using Technologies:* See Understanding >> accessibility support >> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head> >> . >> But that is about assistive technologies and special assisitive features >> in browser. >> >> Perhaps we can tweak that definition to ensure that a user who has a >> fixed orientation is an accessibility requirement for that user, and >> therefore falls under the Conformance Criteria 4 "special accessibility >> features in mainstream user agents". Then we won't have to worry about >> splitting it up... It can go in Perceivable, and the functional aspects are >> covered in the overarching Conformance criterion 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 Mon, Jun 27, 2016 at 3:59 AM, Patrick H. Lauke <redux@splintered.co.uk >> > wrote: >> >>> On 27/06/2016 01:57, David MacDonald wrote: >>> >>>> Hi Patrick >>>> >>>> My thinking is that this fits well under perceivable. I'm hoping that we >>>> will expand Perceivable to >>>> Guideline 1.5 include dynamic and updating content. It might go well in >>>> there. >>>> >>>> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_on_information_added_or_removed_from_a_page >>>> >>> >>> Note that this is NOT about dynamic changes/updates. It's not about how >>> a site/app reacts when orientation/viewport is changed, but rather that it >>> actually works in those orientations/changes (e.g. if a tablet is fixed to >>> landscape orientation and the user accesses a site, NOT about the user >>> accessing the site in portrait and then turning the device into landscape). >>> So no, that's a separate issue from the one I'm talking about. >>> >>> >>> 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 > > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Monday, 27 June 2016 18:08:45 UTC