Re: Sizing SCs

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