RE: What accessibility support exists for low vision?

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<mailto: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<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion