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