Re: Sizing SCs

I agree with Wayne on the 500 % need. Part of having real user-needed
requirements identified is to push innovation. If mobile UAs and devices
can't meet this real user need today, some will strive to do so. So I agree
with the 500%.

For the em vs %, I think Alistair is correct here.

Katie Haritos-Shea
703-371-5545

On Oct 3, 2016 11:51 AM, "Alastair Campbell" <acampbell@nomensa.com> wrote:

> Hi Wayne,
>
>
>
> I’m going to try and separate this into two threads. This one tackles the
> meat of the sizing SC discussion (on LVFT), I’ll reply about the combining
> / separating aspect separately (on WCAG & LVTF).
>
>
>
> Taking a point at time(ish):
>
> > “*Spacial arrangements that prevents sufficient enlargement are
> inaccessible [snip] *
>
> *> The same is true of content that cannot appear in one column (data
> tables excepted) and lines that exceed the viewport width*.“
>
>
>
> Agreed, but there is some content which are by nature special (Maps,
> graphs, games, complex tables, diagrams etc).
>
>
>
> That is why the proposal [1] had the first exclusion: “If the spatial
> layout of some the content *is essential to some of the content's use,
> that part of the content is exempt”*.
>
>
>
> The alternative is to ban those types of content, which the “Text size” SC
> proposal [2] effectively does.
>
>
>
>
>
> *> “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.“*
>
>
>
> The SC needs to work across websites and devices. Can you zoom in 500% on
> your mobile without scrolling?
>
>
>
> What happens on desktops (reduction to 1 column for responsive sites) when
> you zoom in is good, and comes as a result of coding for mobile as well as
> desktop. However, if you apply that same SC on mobile user-agents you
> cannot zoom in *at all* without horizontal scrolling. On mobile UAs the
> layout is determined on-load and you expand/contract the layout, it does
> not re-flow.
>
>
>
> Some mobile UAs have a text-size adjustment, and on some it even works on
> web content (although not on iOS), but going more than 200% will cause
> issues in the same way as non-responsive sites do on the desktop.
>
>
>
>
>
> *> “Why is 500% such a big deal? The mathematical equivalent is done every
> day by authors writing content for mobile?” *
>
>
>
> Not quite, sites generally work from around 1200px wide down to 320px,
> that’s under a 4x difference. Some are 1024px / 320px, which is why I said
> 300% was a safe increase.
>
>
>
> As I said above, it has to work on mobile UAs unless you exclude those.
> That is why we included the exception: “If the user-agent fits the layout
> to the viewport and does not provide a means of reflowing content,
> bidirectional scrolling is exempt.” [1].)
>
>
>
> There is currently a gap in capability for mobile user-agents, where the
> current text-sizing SC (or modified version of that) helps, but increasing
> the text size by 500% on a 4” screen isn’t feasible.
>
>
>
> The available options on mobile UAs are:
>
> ·         Zoom (instant horizontal scrolling)
>
> ·         Increase text size (breaks layouts quickly)
>
> ·         Use the reader view.
>
>
>
> An alternative approach might be to encourage the “reader view” (e.g.
> safari re-formats the page focusing on the content), by requiring authors
> to do things that would make that available in UAs with that feature.
>
>
>
>
>
> *> “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.”*
>
>
>
> Using percentage means that it is relative to the default starting point
> of the web page (from the authors point of view).
>
> EMs/REMs are relative to text-size, but is that the authors or the users
> setting? If it is the authors, from your comment I’d assume you wanted an
> SC like:
>
> “The web page allows the user to zoom in until line lengths are 15em wide
> and the interface should still be usable.”
>
>
>
> Is that what you mean? Again, I think you’d have issues applying that
> across different display sizes and (browser) layout methods.
>
>
>
>
>
> *> “I just cannot see why we don't push for real accessibility, at least
> in the low vision task force.”*
>
>
>
> I’m happy to push for “real” accessibility, but if it cannot be
> implemented then people will ignore the requirement. If people can
> reasonably ignore double-AA requirements because it is known to be
> impossible, then it undermines WCAG as a standard.
>
>
>
> When I run training I can hand-on heart say to teams “You can do this, it
> is all possible” (with the possible exception of audio-descriptions for
> small organisations). If we can’t explain to designers and developers how
> they can meet these new SC then we have a real-world accessibility problem.
>
>
>
> Overall, what I would like to see is SCs that create a testing situation
> such that:
>
> 1.      On UAs that support re-flow, you can zoom to 300% (perhaps
> 4-500%) with no horizontal scrolling or loss of functionality.
>
> 2.      On other UAs or special-content you can adjust the text size to
> 150% without losing content or functionality.
>
>
>
> That wouldn’t be too hard to draft as its own thing, but given the other
> thread, will need to work around the current 1.4.4. I’ll continue thinking
> about this…
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> 1] https://www.w3.org/WAI/GL/wiki/Possible_wording_from_
> Jason/David_for_LVTF_re:_zoom_without_horizontal_scroll
>
> 2] https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Text_Size
>
>
>