Re: Combining the sizing SCs

Dear Alastair,
Spacial arrangements that prevents sufficient enlargement are inaccessible.
This is one of the big accessibility problems faced by people with low
visual acuity. The same is true of content that cannot appear in one column
(data tables excepted) and lines that exceed the viewport width.

Authors can write rich content that meets these constraints. I use a 24
inch and 30 inch monitors. My cell phone is 6 inches. For many sites the
same code runs on both. That is a 1/400% to 1/500% contraction. This is
done by conversion to 1 column. The concept of imposing bi-directional
scrolling on normal readers is not considered as an option. Developers just
do what needs to be done to catch the mobile market. They don't use any
special UA  features. They do it all with HTML, CSS and JavaScript.

Why is 500% such a big deal? The mathematical equivalent is done every day
by authors writing content for mobile? We have a  print disability that can
be ended today with contemporary content authoring practices. I just cannot
see why we don't push for real accessibility, at least in the low vision
task force.

I do not think percent is the metric to use. I think EM or REM per line is
the measure. On any device there should be a usable interface with line
length, 15 EM or REM that fills lines. This gives 15 to 20 characters per
line.  That is a testable metric.

Wayne










On Mon, Oct 3, 2016 at 5:05 AM, Katie Haritos-Shea <ryladog@gmail.com>
wrote:

> Alistair,
>
> While this seems like a good idea, remember that 2.1 has to be 100%
> backwards compatable (in that it will add new things, but all of the old
> things will still be true), so it may be more complicated to so.
>
> In other words you would still have to have the Resize SC (with it
> existing number) and a Resize Text plus Resize Content (with a new number).
> So it seems best to just make the new idea, Resize Content by itself the
> new number.
>
> We *do* want to combine all NEW SC ideas as much as we can, but combining
> old with a new will be much harder to do, considering our requirements for
> 2.1.
>
> Do others agree or disagree that this is consistant with one of the goals
> of 2.1?
>
> Katie Haritos-Shea
> 703-371-5545
>
> On Oct 3, 2016 4:59 AM, "Alastair Campbell" <acampbell@nomensa.com> wrote:
>
>> Hi everyone,
>>
>>
>>
>> I’m not sure how many people track the github issues, but I added one on
>> Friday about the sizing SCs:
>>
>> https://github.com/w3c/low-vision-SC/issues/16
>>
>>
>>
>> It covers the issues that came up at the meeting in TPAC, and proposes a
>> replacement for Sizing All Content & Text-Sizing.
>>
>>
>>
>> I don’t have access to editing the LVTF wiki area, but it’s probably best
>> to have a new one and copy over some of the associated text for benefits,
>> techniques etc.
>>
>>
>>
>> Is it best to discuss on-list or on-github?
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>>
>>
>> --
>>
>>
>>
>> Alastair Campbell
>>
>>
>>
>> www.nomensa.com
>>
>> tel: +44 (0)117 929 7333 / 07970 879 653
>>
>> follow us: @we_are_nomensa or me: @alastc
>>
>>
>>
>> Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT
>>
>> Company number: 4214477 | UK VAT registration: GB 771727411
>>
>