- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 27 Jun 2016 12:02:39 -0500
- To: David MacDonald <david100@sympatico.ca>
- Cc: "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
- Message-ID: <CAKdCpxxgPcXFBKCaAi6zFzsbz73hQfEw2HSqCxbGdZAkvHnOJQ@mail.gmail.com>
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
Received on Monday, 27 June 2016 17:03:10 UTC