- From: Wayne Dick <wayneedick@gmail.com>
- Date: Mon, 3 Oct 2016 07:28:45 -0700
- To: Katie Haritos-Shea <ryladog@gmail.com>
- Cc: AlastairCampbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
- Message-ID: <CAJeQ8SAsot8Q_NHj8x6jv3Fe0O3+i6CR9U2pLNgAnHFw2pPuRQ@mail.gmail.com>
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 >> >
Received on Monday, 3 October 2016 14:30:00 UTC