Re: Principle 4 - Robust (was Re: Help needed with numbering success criteria for WCAG 2.1)

Hi John


   - So I guess you mean you would like to see it in Principle 4. Do you
   have a proposal? I think it could go either place.
   - Principle 4 as you suggest, or Principle 1 (understanding that
   Conformance Criteria 4 requires it to work if we make clear some users have
   their device locked in a specific orientation on a wheelchair 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 Mon, Jun 27, 2016 at 1: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
>
>
>

Received on Monday, 27 June 2016 18:34:07 UTC