Re: Moving Issues 62, 63, 71 to the conformance section

> So, the argument would have to be that the “accessibility supported
mechanism” is to either go find a laptop or desktop or to go to a different
webpage, which is an absurdly loose interpretation taken way out of context.

Many mobile pages have a difficult to find (but conforming) link at the
bottom called "desktop version". This loads the desktop version into the
mobile browser.

Under our definition, I believe that would conform to #1 if the desktop
site conformed. Moreover, WCAG accessibility support only requires one
supported stack. And it could be argued that Windows desktop, Chrome, JAWS
is that stack, even without that link.

Now having said, 98% of evaluators will fail a page with a breakpoint that
has an inaccessible mobile menu. (1) So I maintain that it is largely
academic until it is seriously challenged by a defense in one of the many
cases that are currently pending.

(1) https://twitter.com/davidmacd/status/885863118517264385

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005

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 Sat, Jul 15, 2017 at 1:59 PM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> wrote:

> Hi David,
>
>
>
> This question seems ancillary to the issues surrounding conformance of
> breakpoints in a webpage, although certainly important.
>
>
>
> When I look at the definition for a conforming alternate version
> <https://www.w3.org/TR/WCAG21/#dfn-conforming-alternate-version> in WCAG,
> I’m having a tough time seeing any ambiguity as to whether or not a desktop
> version can be claimed as an alternate for an inaccessible mobile version,
> unless there’s an explicit link to it.  Requirement 4 states:
>
>
>
> “4. for which at least one of the following is true:
>
> 1.  the conforming version can be reached from the non-conforming page via
> an accessibility-supported mechanism, or
>
> 2. the non-conforming version can only be reached from the conforming
> version, or
>
> 3. the non-conforming version can only be reached from a conforming page
> that also provides a mechanism to reach the conforming version”
>
>
>
> So, the argument would have to be that the “accessibility supported
> mechanism” is to either go find a laptop or desktop or to go to a different
> webpage, which is an absurdly loose interpretation taken way out of context.
>
>
>
> What am I missing?
>
>
>
> Steve
>
>
>
> *From:* David MacDonald [mailto:david@can-adapt.com]
> *Sent:* Friday, July 14, 2017 3:16 PM
>
> *To:* Kathy Wahlbin <kathy@interactiveaccessibility.com>
> *Cc:* John Foliot <john.foliot@deque.com>; White, Jason J <jjwhite@ets.org>;
> WCAG <w3c-wai-gl@w3.org>
> *Subject:* Re: Moving Issues 62, 63, 71 to the conformance section
>
>
>
> I actually have a Twitter survey out right now, to poll WCAG Evaluators
> what they consider with respect to responsive Menus. (1)
>
>
>
> The good news is that 97% (29/1) right now that evaluators will fail a
> hamburger menu that is non conforming on a responsive site even if the main
> desktop version passes.
>
>
>
> So the interpretation that the desktop version is the "conforming
> alternative" is mostly theoretical, out in the wild they are given a fail.
>
>
>
> I admit that I file WCAG failures for messed up hamburger menus  even if
> there is a conforming desktop menu also. Loretta, the former editor of WCAG
> also holds this view. See issue  197 (2)
>
>
>
> However, when trying to introduce language to the WCAG 2 to formalize
> this, got completely bogged down, and I closed the issue and reintrodiced
> it to WCGA 2.1 (3)
>
>
>
> But for some reason this is bogging down also, so I'm thinking I'll just
> drop the proposal and let it continue to get sorted out in the wild, until
> someone gets hit with a legal challenge.
>
>
>
>
>
> (1) https://twitter.com/davidmacd/status/885863118517264385
>
> (2)  https://github.com/w3c/wcag/issues/197
>
> (3) https://github.com/w3c/wcag21/issues/19
>
>
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> 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 Fri, Jul 14, 2017 at 2:58 PM, Kathy Wahlbin <kathy@
> interactiveaccessibility.com> wrote:
>
> With responsive design, these can be seen on the desktop when the screen
> is magnified.  These are not just for mobile so I don’t think we should say
> that we need to test on one mobile platform since it does not matter what
> device that you are using.  My surface PC has a smaller screen that is
> actually smaller than the iPAD pro.
>
>
>
> Kathy
>
>
>
> *From:* David MacDonald [mailto:david@can-adapt.com]
> *Sent:* Friday, July 14, 2017 2:16 PM
> *To:* Kathy Wahlbin <kathy@interactiveaccessibility.com>
> *Cc:* John Foliot <john.foliot@deque.com>; White, Jason J <jjwhite@ets.org>;
> WCAG <w3c-wai-gl@w3.org>
>
>
> *Subject:* Re: Moving Issues 62, 63, 71 to the conformance section
>
>
>
> hmmm...
>
>
>
> What do you think WCAG 2.0 requires?
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> 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 Fri, Jul 14, 2017 at 1:54 PM, Kathy Wahlbin <kathy@
> interactiveaccessibility.com> wrote:
>
> I agree with John.  We should not say that they have to have it working on
> one mobile technology.
>
>
>
> This is also not an SC.  We are proposing adding clarification language to
> the Understanding Requirement 2" just before the Notes at the end of the
> section. https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-
> conformance-requirements-head to clarify that different viewport sizes
> also need to conform to WCAG SC.
>
>
>
> Kathy
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Friday, July 14, 2017 1:47 PM
> *To:* David MacDonald <david@can-adapt.com>
> *Cc:* White, Jason J <jjwhite@ets.org>; WCAG <w3c-wai-gl@w3.org>
>
>
> *Subject:* Re: Moving Issues 62, 63, 71 to the conformance section
>
>
>
> Hi David,
>
>
>
> > If they can demonstrate the site working on one mobile technology stack
> that should be sufficient.
>
>
>
> I'm sorry, I have to *strongly *disagree with that. The W3C has a
> long-standing policy of two independent implementations, and I would expect
> we maintain that minimum requirement going forward.
>
>
>
> I cannot support a SC that is targeted towards addressing an issue (or
> issues) with a specific piece of hardware or software (or platform), and if
> we cannot demonstrate that the requirement can be achieved on more than one
> platform, then we cannot make it a SC Requirement today (hard as that may
> be to accept). As somebody once noted
> <http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html#p7>:
>
> Success Criteria are technology neutral
>
>
>
> JF
>
>
>
> On Fri, Jul 14, 2017 at 11:57 AM, David MacDonald <david@can-adapt.com>
> wrote:
>
> > Try as I might, I've not gotten VoiceOver to work on my Samsung Galaxy
> yet, and I don't think I ever will...
>
>
>
> Yes it is shorthand, however, I don't think we can require developers to
> support every environment. Especially buggy environments ...  (such as
> Talkback/Android)
>
>
>
> If they can demonstrate the site working on one mobile technology stack
> that should be sufficient.
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> 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 Fri, Jul 14, 2017 at 12:37 PM, John Foliot <john.foliot@deque.com>
> wrote:
>
> As an aside...
>
>
>
> > The original intention of the SC is to require VoiceOver compatibility
> for mobile views
>
>
>
> Try as I might, I've not gotten VoiceOver to work on my Samsung Galaxy
> yet, and I don't think I ever will...
>
>
>
> (I realize that this was more "shorthand" than anything else, but we also
> need to be mindful that we are looking for functional outcomes, and not SC
> that address software shortcomings with specific tools - which I know David
> knows. 😀)
>
>
>
> JF
>
>
>
> On Thu, Jul 13, 2017 at 8:04 PM, David MacDonald <david@can-adapt.com>
> wrote:
>
> Hi Jason
>
>
>
> The original intention of the SC is to require VoiceOver compatibility for
> mobile views, especially inaccessible hamburger menus. Personally, I'd like
> to simply see a qualification to WCAG 2.0 or 2.1 Conformance that a page
> includes changes caused by breakpoints.
>
>
>
> Your wording requires ALL AT to be tested and we found that to be a
> limitless scope of every AT available in the Apple store. We could narrow
> the scope by limiting the AT the way we did in the SC proposals to
> "platform assistive technology that remaps touch gestures". This is really
> the crux of the problem as we saw it on the task force.
>
>
>
> ***
>
> If (1) the content includes features that adapt the presentation or
> functionality for specific hardware or software environments (e.g., as
> rendered on devices with different screen sizes), and (2) a different
> platform assistive technology that remaps touch gestures is used on those
> environments then the ways in which technologies are relied upon to satisfy
> the success criteria are only accessibility-supported if they are
> compatible with user agents and assistive technologies in each of the
> environments for which enhancements are provided.
>
> ***
>
>
>
> I know its a mouthful but if its accurate we can do a plain language pass
> later.
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> 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 Thu, Jul 13, 2017 at 4:46 PM, White, Jason J <jjwhite@ets.org> wrote:
>
> This is interesting. I don’t think screen size is the right concept to use
> for purposes of of the clarification that we need. Also, this proposal
> doesn’t actually clarify the application of the “accessibility-supported”
> requirement by asserting the relevant set of user agents and assistive
> technologies that need to be compatible with the ways of using technologies
> relied on to meet the success criteria. I appreciate its simplicity,
> however.
>
>
>
> *From:* David MacDonald [mailto:david@can-adapt.com]
> *Sent:* Thursday, July 13, 2017 4:39 PM
> *To:* White, Jason J <jjwhite@ets.org>
> *Cc:* WCAG <w3c-wai-gl@w3.org>
> *Subject:* Re: Moving Issues 62, 63, 71 to the conformance section
>
>
>
> Here's another option which might be easier:
>
>
>
> ***
>
>
>
> "If components change form based on screen size, they remain
> programmatically determinable and keyboard operable."
>
>
>
> ***
>
>
>
> It would be placed after the last paragraph in the section "Understanding
> Requirement 2" just before the Notes at the end of the section.
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-
> conformance-requirements-head
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FUNDERSTANDING-WCAG20%2Fconformance.html%23uc-conformance-requirements-head&data=02%7C01%7Cjjwhite%40ets.org%7Cc5e18b0d103d4893abe408d4ca2f3ddf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636355751636405902&sdata=OzSa6RsINaMaOkGRz5hP6NJHqSU8BoO86HE7OGWPrVw%3D&reserved=0>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Mobile:  613.806.9005 <(613)%20806-9005>
>
> LinkedIn
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7Cjjwhite%40ets.org%7Cc5e18b0d103d4893abe408d4ca2f3ddf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636355751636405902&sdata=EB3oYNzfR2hkc1qw6IbuaCsDcEc8ZU06qljcnuXQQAo%3D&reserved=0>
>
> twitter.com/davidmacd
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7Cjjwhite%40ets.org%7Cc5e18b0d103d4893abe408d4ca2f3ddf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636355751636405902&sdata=QtuGL8qoBb92JkUa87O%2Bt6l0JmOqZxrzu5lI4GuGy5M%3D&reserved=0>
>
> GitHub
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7Cjjwhite%40ets.org%7Cc5e18b0d103d4893abe408d4ca2f3ddf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636355751636405902&sdata=vyZLBGm1BRgreiXBLdYxV4z%2Bnz32zcW9yZ8te9QQCsI%3D&reserved=0>
>
> www.Can-Adapt.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cc5e18b0d103d4893abe408d4ca2f3ddf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636355751636405902&sdata=uSTGQHJwALkXIBDE0NfG%2BrfFzN9pAH4kXR5YNYXnwH0%3D&reserved=0>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7Cjjwhite%40ets.org%7Cc5e18b0d103d4893abe408d4ca2f3ddf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636355751636405902&sdata=arDC0ucVLw4b1n%2BnUUjj4ZfdTTpk3XOuENhWpddbRPA%3D&reserved=0>
>
>
>
> On Wed, Jul 12, 2017 at 12:50 PM, White, Jason J <jjwhite@ets.org> wrote:
>
> Thanks, David – see further comments below.
>
>
>
> *From:* David MacDonald [mailto:david@can-adapt.com]
>
> I like your second condition, adding an "AND" for different AT in those
> environments.
>
>
>
>  Regarding the first condition, Gregg expressed concern regarding using
> broad strokes for the customized view. He suggested we limit it to "size".
> He was nervous that there might be customized delivery of content such
> information spoken in a car etc, that by its very nature could not meet the
> conformance language and inhibit adoption of the standard.
>
> *[Jason] I would like to see good examples of this that would meet both of
> my conditions and which would raise difficulties.*
>
>
>
> So if I was to take your proposal and adjust it to size, it would look
> something like this.
>
>
>
> If (1) the content includes features that adapt its presentation or
> functionality based on screen sizes in specific hardware or software
> environments, and (2) different user agents or assistive technologies are
> in use in each of these respective environments, then the ways in which
> technologies are relied upon to satisfy the success criteria are only
> accessibility-supported if they are compatible with user agents and
> assistive technologies in each of the environments for which adaptations
> are provided.
>
>
>
> However, arguing against myself, your proposal  does limit the scope to
> environments with different AT. If there is no AT for that environment,
> then maybe your language is OK.
>
> *[Jason] Yes, I’m in favor of mentioning screen size, if at all, only as
> an example. Both of the conditions do need to be met for the proposal to
> apply, and it only clarifies (at most, expands) the nature of the
> compatibility guarantee.*
>
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
>
>
> Thank you for your compliance.
> ------------------------------
>
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
>
>
> Thank you for your compliance.
> ------------------------------
>
>
>
>
>
>
>
> --
>
> 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
>
>
>
>
>