Low Vision Accessibility Task Force Teleconference -- 06 Oct 2016

<shawn> ** informal, chair-less meeting **

<shawn> scribe: Alastair

<scribe> scribe: alastairc

<shawn> scribenick: alastairc

Shawn: Some great discussion on list, we can go forward and work on some of the open issues.

Wayne: Let's work out an agenda. Perhaps text resize and reflow would be a good start.

Text size and Reflow

Wayne: One of my visions for this was that original US 508 included the idea that reading order of the page would be a reading order, and you could drop the styles and have a readable, usable document.
... It was a tremendous thing, I used to have de-constructive style sheets which would reset everything down to HTML, then build the style that was needed.
... More and more that has become tricky, can't do it with (just) style sheets anymore. Removing CSS and linearising the page is still a useful test.
... Something that makes it harder is that web pages include storing data. People do that by making it un-perceivable, e.g. display: none. That's ok, but it means there is lots of clutter in there which isn't intended to be seen.
... Wanted to keep the concept of technology agnostic, but there are things like elements in any document language, and I think all have the nesting properties. I put those as basic ground rules, and when we are talking about elements, then applying a reading order.

<laura> Reflow to Single Column SC that Wayne drafted: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Reflow_to_Single_Column

Wayne: Reflow may not be the thing, might be proper reading order. Anytime in the run-time, if you take a snapshot should make sense in the order of the source code.
... Put that forward as a proposal so that without style it is still readable and operable.
... the utility is that it allows font-size to be truly adjustable, and provides access within the browser.

<Wayne> Alaaster: We thing it would be difficult to have something that makes things that are ordered way to read content that would support leaving style out.

<laura> Possible wording from Jason/David for LVTF re: zoom without horizontal scroll: https://www.w3.org/WAI/GL/wiki/Possible_wording_from_Jason/David_for_LVTF_re:_zoom_without_horizontal_scroll

<Wayne> ... Text size - content can be enlarged to x-percent with full function and no 2-directional scrolling with exceptions: (1) 2D rigid objects, (2) Mobile load is fixed. They have their width so it cannot be supported on mobile.

<ScottM> I think asking authors to support removal of their style sheets is going to be a non-starter at this point. Things are so complex these days it is difficult to have a an easy way to remove or replace styles

<ScottM> supporting text reflow is good

<ScottM> intelligent support for zooming is also good

Wayne: Something from WCAG 2.0 that wasn't forseen, was that 1.3.1 and 1.3.2 they focused on the text to speach model, and the group didn't dream that these would (want to be) be applied in different ways.
... Maybe what we need to do is to say that we have these cases to add to 1.3.1 & 1.3.2 that are important, and will make the difference between being able to use the browser, and not for the group.
... They weren't recognised as being as important as they are, now with cell phones people saw the bi-direction scrolling problem. Now people see some of the things that weren't clear before.
... People are worried about expanding the meaning "forever", but there are specific things we can pull out for 1.3.1/1.3.2 that we can now identify well.

Glenda: I like the concept of it being in 1.3.1/1.32, but it might be good for us to offer it both ways. People like choice, so we can say: would you like to add these as new SC, or add to the previous ones.
... then it isn't whether, it is how.

Wayne: any other thoughts?

Glenda: One of the most powerful things I experienced was research you worked on, with people reading with scrolling, if we could have an example like that it would reduce barriers for acceptance.

<Wayne> Alastair: More functional vs. Text oriented. More scripting may not be as useful.

Scott: Removing style sheets is one of the things, particularly in the last 10 years, we've had to tell clients to ignore this criteria. Many of the sites are applications now. Used to be doc focused, but now it is more app focused. They have a lot of structural glue, if you reflow they might not make sense.

<Glenda> reflow into a single column + landmark navigation (for all people) would be a great solution (and I can envision it be handling by browsers)

Scott: Screenreaders are able to deal with this to some extent, but visually, if you reflow it into one ribbon of text, there is a lot of layout information is completely destroyed.
... I think it is part of the reason that browser switched to zoom instead of text-sizing.

<Wayne> q

Scott: how do we reconcile that? Reflow, and having documents created in a reading order. Issues with simulated order where dialogues are put at the end of the page.
... You can end up with dialogues at the end of the DOM, not where you triggered it from. For LV, how do we reconcile that? Most people won't be replacing their style sheets, they might turn on high-contrast mode?
... If you are talking mobile devices, it may not work.
... Not keen on the controls you might find on sites which allow text sizing/colours. How do we create language that allows authors to support different text sizes, to have the UI reflow? The reader-mode in browsers is good, that would be a good thing to support. Could that be built into the page?

<ScottM> hakim help

Wayne: Applications - when you write an app, it seems like (from user point of view). the idea of maintaining a readable order is really not as hard as you might think. You only need to be responsible for the things you can see. It is about looking at the cases as you make the programme.
... That goes with content management system insertion as well. Apps can only go through as many cases as you create. From dev point of view it is a process, and would be something we'd have to teach, but it isn't that different from other accessibility concepts. But it is a new one, that's why the proposed text has the complex looking text.
... from user perspective, what we don't use a lot is the power of WCAG 2. I use NVDA and a lot of times I turn the voice off and use it for navigation. When web pages have reasonable linearisation, we could use our own navigators to get around a linearised view. You'd have as good access as screenreaders. Would be nicer to see everything at once, but if you can't, a linear view with navigation is best.
... There are UI issues, but right now we can't use WCAG 2.0 to it's best advantage, and some things just aren't visible to some of us. Although it's a little hard to search in 1 column (due to lots of scrolling), but you don't miss the thing on the right hand side that falls into a blind spot. You don't miss things, that's very useful.
... For those at CSUN, we'll be demo-ing a new UI for creating you own stylesheets.

<shawn> Alastair: I think a lot of the issues when applying user style sheets or disabling styles come from showing content that is supposed to be hidden, we need to make sure people leave display: none alone.

Wayne: We have some good examples lined up, which are WCAG 2 and responsive. E.g. a news site. Might have to go through different classes of site. Might also have quick ways of doing things.

<Glenda> If landmark roles become required in 2.1, would reader view be much more possible?

Wayne: One thing the order knows is what the meaningful reading of their content is, because they wrote it!
... If they can let us know how to step through it. What we do with it is then up to us.

Glenda: What if we make landmark roles a requirement of 2.1?

Wayne: that would help.

Glenda: There's so much to be gained by that, thinking about the reader view, perhaps browsers adding ability to jump to main without needing a screenreader.

<laura> Save Us From Skip Links: https://www.epinova.no/en/blog/save-us-from-skip-links/

Glenda: I'd like browsers to give us a keyboard combo to move to landmark roles, main, nav, search, without having to open a screenreader. I think we can sell this from an SEO point of view as well, the page highlights what is in <main>.

https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Text_Size

https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Size_of_all_elements

And an alternative: https://www.w3.org/WAI/GL/wiki/Possible_wording_from_Jason/David_for_LVTF_re:_zoom_without_horizontal_scroll#Version_4

<laura> Seeing All Interface Elements: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Seeing_All_Interface_Elements

https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Seeing_All_Interface_Elements

<laura> AC: suggests combining

ac: Suggest combining Size of all elements & Content sizing

Glenda: Can we use the WCAG 2.0 contrast number approach?
... e.g. 300% for 2.1 level A, perhaps more for AA.

https://www.w3.org/WAI/GL/wiki/Possible_wording_from_Jason/David_for_LVTF_re:_zoom_without_horizontal_scroll#Version_4

Wayne: The 2nd exception - that's when you meant content that is in a rigid object
... If the text itself is embedded in the object?
... A problem is a table, and it's meaning comes from 2 dimensions. What's useful in a table, is that each table cell fits in a screen, at least horizontally if not vertically.
... In something like a graph, points & lines with labels. Would seem reasonable that the labels to not go off the screen?
... If you have text embedded in an image, and the positioning is critical, the text is still within a container?

Glenda: Why don't I want to enlarge the whole thing? Because the presentation of the text is in relationship with the imagery, that seems ok.

Wayne: You're probably right...

Glenda: E.g. digital art that includes text.

<shawn> +1 for important for element level -- important that it doesn't screw up the rest of the page

Wayne: Any other thoughts?

Scott: The map thing is interesting, I've had some frustrations with maps. I couldn't see the text, enlarged it, but the font size didn't change, or get smaller! Or they'd name some streets but not others due to the zoom level. Ideally, if you have content that is highly dependant on layout, you will be very limited in ability to increase text size independent of that. how you do that in a way that makes sense, when do you throw in the towel and allow

horizontal scrolling.

<Wayne> + 1

Scott: There are some things you can do with gmail interface to reduce horizontal scrolling, you could stack columns, instead of horizontal scrolling, but how do we give authors that flexibility without it being just linearised. Seen people at a certain breakpoint completely change it, and take things out. See it a lot with RWD sites, have 10 features on desktop, then at phone size you only get 5. Takes away functionality.
... sometimes you might have to clue people into scrolling on mobile, especially with magnification.

AC: For hiding things, isn't that what the 'see all interface elements' comes in?

Wayne: It is important that we don't allow people to claim it is an important layout.
... Important concept, text sizing vs geometric enlargements.
... We're talking about objects that are geometric, whereas other things the geometry isn't critical to it's use

AC: Can i combine this one with the size all content.

Wayne: lets get you on the wiki.

Erich: I agree from experience point of view, agreeing with Scott, esp on maps.

Wayne: When I blow up maps, I feel like I'm walking along them, nose against the screen!

<laura> would love Alastair to work on the size of all content SC and incorporate his text.

Wayne: When we put a % on it, we have an issue with people wanting to make it as big as is practical.

<Glenda> What is optimal line length?

Wayne: If you start with 8pt font, 200% isn't much.

<Glenda> Size Matters: Balancing Line Length and Font Size in Responsive Design https://www.smashingmagazine.com/2014/09/balancing-line-length-font-size-responsive-web-design/

<laura> Why couldn’t we set base default of say 1 em or 100%

<Wayne> alastairc: How would an author define line length. Given a starting point. Assume that authors start with a reasonable staring point. More compatible with mobile the better. When you go beyound 300 you need linearization.

ac: I think the way that it works with multiplying from the starting point by 4 (400%), then moving to reflow by the user.

Wayne: I don't use mobile devices much, don't have one for listening, just use for checking tiny things and making calls. As a web device it isn't too useful. At a certain point, a small screen may not work, can't use it visually.

Glenda: Yep, or you need a larger device. When I read at night I do use my iphone, but I take my glasses off and read with my worst eye. This device is 31 characters across.

Wayne: Right now we don't have sufficient tech to help with that.

<Glenda> What is too narrow? Interesting article “Line Lengths and Column Width” http://www.magazinedesigning.com/columns-pt-2-line-lengths-and-column-width/ There is a section that has a heading of “Importance of line length and column width” that says character counts of 25-30 is too narrow.

<shawn> Thanks all for good discussion. /me agrees easier than e-mail

<laura> Bye. Thanks all.

- DRAFT -

Low Vision Accessibility Task Force Teleconference

06 Oct 2016

Attendees

Contents

Text size and Reflow

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output