Re: What accessibility support exists for low vision?

Hi John,
My comments are not for 2.1. Like personalization, this exceeds the scope
of 2.anything.

However, as we end this process it is important to note remaining gaps.

When the group finished 2.0, we thought accessibility support existed. Now,
from our digging into this problem, we understand what we thought was
accessibility support was not.

Any assistive technology may not be effective enough to qualify as
accessibility support. That is the case of zoom. Well executed responsive
design turns browser zoom into an extremely effective assistive technology,
that could be a candidate for accessibility support. Unfortunately it is
too infrequently distributed at this time to give accessibility support.

The 2.1 discussions have been incredibly useful in uncovering the barriers
that will need to be addressed when we begin a new guideline with new
assumptions. We know that for low vision there is a  path to accessibility
support. Like cognitive it is personalization applied to a different set of
parameters.

To address this we will need the user agent, authoring tool and content
issues combined into one guideline.

So, as we leave the 2.1 process lets simply remember. We have uncovered
during the research for 2.1 is:

No assistive technology has the quality or distribution to qualify for
accessibility support for low vision. We have done the best we can, and
that is a lot.

Wayne

Wayne


On Wed, Jul 19, 2017 at 2:03 PM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> I think I can clear up a couple of points of  confusion:
>
>
>
> Initially Wayne meant magnification (without reflow) is not a real
> adaptation for people with low vision.
>
>
>
> Things are improving with responsive design and the zoom SC, but there are
> some issues to tackle even with that. (E.g. sticky headers.) We’ll get what
> we can into 2.1.
>
>
>
> I’ll leave the other items for now, trying to keep some focus.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
> *From:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* 19 July 2017 17:38
> *To:* GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
> *Subject:* Re: What accessibility support exists for low vision?
>
>
>
> Hi Wayne,
>
>
>
> OK, so now I am confused. As an advocate and educator I don't know how to
> respond.
>
>
>
> You started this thread by stating (and I will quote directly), "One
> thing that we have proved is that zoom is not accessibility support. My
> work on reading has shown that *zoom is very possibly the worst user
> interface in existence.*" (emphasis mine).
>
>
>
> Yet 12 hours later you write, "The fact still remain that responsive
> design (done correctly) makes *browser zoom the first accessibility
> support for low vision that has existed" * and, "*The standard user agent
> technology becomes the best assistive technology available for users with
> low vision to read the web*"
>
>
>
> Which is it?
>
>
>
> Accessibility Supported
> <https://www.w3.org/TR/WCAG20/#accessibility-supporteddef> - the
> normative definition in WCAG says "...*supported by users' **assistive
> technologies* <https://www.w3.org/TR/WCAG20/#atdef>* as well as the
> accessibility features in browsers and other **user agents*
> <https://www.w3.org/TR/WCAG20/#useragentdef>", which I can only take to
> refer to your statement "The standard user agent technology becomes the
> best assistive technology available for users with low vision to read the
> web" - which means that it's not an "accessibility support" issue at all -
> it's an authoring techniques issue, which is fair enough, but a completely
> different thing.
>
>
>
>
>
> In a subsequent email, you stated a number of Do's and Don'ts, and my
> question is, is this what you believe is required from WCAG? Are these ALL
> the authoring requirements you feel are critical for "success", up to the
> point that we make them 'normative requirements'? Can we even do that?  I
> don't know.
>
>
>
> Do:
>
>   * *Use symmetric responsive design*
>
> As Patrick points out, this is a new term, and honestly, one that doesn't
> add to the existing understanding of "responsive design".
>
>
> Can we mandate that all sites use responsive design? I don't think we can.
>
>
>
> At best we can make that a strong Best Practice, but not all sites or site
> content will lend themselves to a responsive interface, and so we have to
> be metered in our demand here. For example, how do we apply this to PDFs
> (given that PDF is considered a "web technology" and we already have
> techniques for success specific to PDF in WCAG 2.0)?
>
>
>
>   * *Make a break point class for resolution 320 by 180*
>
> My reading of your emails lends me to believe that this is a critical
> aspect of your 'ask' - that a breakpoint like this makes a lot of the other
> accommodations needed possible, without having a significant impact on
> readability.
>
>
>
> That for me is a huge take-away, but how do we make that a normative
> requirement? I'm not sure, but I think we can figure out something there.
>
> (*extremely rough draft: For content that uses Responsive Design
> techniques, authors must provide a breakpoint that supports a 320 X 180
> resolution*)
>
>
>
> That won't solve *all* problems, but it kicks the ball in the right
> direction (would you agree?)
>
>
>
>   *
> *Use Expand / Collapse to give a users a time based sequence of full
> screen interactions with applications*
>
> Again, I don't see how we can mandate this, in part because it is very
> technology specific - how do we accomplish this in PDF? Will content
> publishers (I'm thinking in the context of ePub and EDU publishers like
> Pearson) be 'allowed' contractually to make these types of adaptations? (I
> really don't know).
>
>
>
> Again, I think this is an important, perhaps critical Best Practice, but I
> don't see how we can make a normative requirement out of this.
>
>
>
>   * *Use appropriate inline markup to enable adaptation of text*
>
> I believe we are getting this into 2.1:
>
> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0201.html
>
>
> Don't
> (Part of the problem here is that you have provided some "Don'ts, but WCAG
> isn't written that way, so this and the other "Don'ts" need to be
> re-configured as functional outcomes, and not negative requirements)
>
>
>   * *Use fixed position banners*
>
> This is a very broad and sweeping requirement, and one I think we'll see a
> huge amount of push-back on.
>
>
>
> There are a significant number of websites out there that currently depend
> on "banner ads" as part of their revenue stream, and that industry has standardized
> on fixed sizes for their banners
> <https://www.iab.com/guidelines/iab-standard-ad-unit-portfolio/>. Now,
> they *have* adapted to the responsive world of web-design, but because they
> are still working with fixed-size banner ads, there will be some 'placement
> constraints' related to that fact.
>
>
>
> I see this now as another one for the Best Practice pile.
>
>
>
>   * *Force the main area to occupy less than 80% of the screen space​*
>
> I'm not 100% sure I fully understand you: are you saying that the <main>
> region in a web-page MUST NOT be less than 80% of: the full screen area,
> the screen width, or the screen height?
>
>
>
> Again, how does a content author support that in PDF? How do we test for
> that?
>
> We *might* be able to take this and re-craft it to a SC, but again at best
> I think it would be a conditional SC, and not applicable in all instances
> of web technologies today.
>
>
>
>   *
> *Put controls in the middle of the main page area without an on / off
> mechanism*
>
> Again, this is very technology specific, and does not apply to all web
> content.
>
>
>
> Additionally, I find this a bit confusing: I read this as saying that *if*
> a content author puts "controls" in the middle (horizontal middle? vertical
> middle? what is "middle" in a endlessly scrolling page like Facebook?) of
> the page, a mechanism must exist to show/hide those controls that can be
> activated by the end-user.
>
>
>
> If that is the case, does the current "personalization" SC that we
> discussed Tuesday (and we will be meeting on this morning) point us in the
> right direction? (More specifically, I am asking about my suggested AA SC,
> as articulated here:
>
> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0217.html​,
> where a semantically identified region could be "hidden" or exposed using a
> browser plug-in or similar solution)​
>
>
>
>   * *Put sprites in background images.*
>
> Sadly, that ship has sailed, and I don't think we can unscramble that egg
> (to mix my metaphors).
>
>
>
> To move this requirement forward will require 2 things:
>
>
>    1. a robust replacement for the existing technique(s) that are
>    background sprites, with something that is more accessible
>    2. a concerted educational effort to promote the use of the "new"
>    technique versus the old background sprites technique
>
> This of course will take time. Today, again, at best I think we can make
> this a Best Practice, but given how much this technique is out there today,
> we cannot 'forbid' its use without a functional replacement - we'll just
> get push-back and out-right ignoring of this requirement otherwise.
>
>
>
> Wayne, from your list of 4 Do's and 4 Don'ts, I can generously see 3,
> maybe 4 potential SC (one of which is already at CfC, another is being
> deeply discussed right now, and 2 "maybe's" from above: mandated break
> point and the 80% <main> requirement - both would require some serious
> word-smithing).
>
>
>
> However, that leaves another 4 that are either unachievable or will pose a
> serious "undue-burden" situation for content creators, and so I believe
> that at best we can only bring forward some Best Practices to address those
> issues today.
>
>
>
> But, with Best Practices and a focused educational campaign, I think that
> we could move the needle significantly forward to address the reading needs
> of low vision users on the web today. It may not be perfect, and it will
> take some time (as it did for sites and "screen reader support" - I've
> watched that trajectory for close to 20 years now, and in that
> retrospective we've come a very long way), but I honestly believe that this
> can be achieved.
>
>
>
> Thoughts?
>
>
>
> JF
>
>
>
>
>
> On Wed, Jul 19, 2017 at 5:59 AM, <michiel.list@moiety.me> wrote:
>
> > Wayne Dick wrote:
> >
> > Perhaps we only need to point out is that the landscape break
> > point should exist always. That would address fixed banners take 3/4 of
> the
> > space leaving 1/4 for main.
>
> What do you mean with “landscape break point should always exist”? Why is
> that?
>
> — Michiel
>
>
>
>
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>