Re: What accessibility support exists for low vision?

We may be able to include some requirements around sticky headers and
footers, but lets worry about that after August.

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 Wed, Jul 19, 2017 at 10:59 AM, Wayne Dick <wayneedick@gmail.com> wrote:

> ​Hi Micheal,
>
> Keep in mind, this is not for changing the direction of 2.1. It is an
> observation for silver.
>
> Responsive design was not developed with content enlargement in mind. It
> was meant to accommodate changes in display size.
>
> Currently an author who creates a break point for 320px width has a
> portrait mobile device in mine.  They are thinking of a logical resolution
> of 360 by something like 568. This means authors set fixed size and
> position items at the top and bottom of a page. That burns up a lot of
> space, top and bottom, but in portrait mode the room is still there for the
> main content.
>
> The logical space for large print has resolution 320 by 180. There is
> literally no room for banners. or they must flow out of the was.
>
> That is what I mean. I originally used symmetric to emphasize keeping more
> than hardware uses in mind when designing break points. Designing for
> enlargement creates different cases that are not covered in many cases.
>
> I am sorry that I cannot give the url, but Alastair and Steve R have
> collected a lot of cases.
>
> Responsive design with disability in mind is different than responsive
> design with hardware in mind.
>
> Does that answer?
>
> Wayne
>
>
>
>
> ​
>
>