Low Vision Accessibility Task Force Teleconference -- 07 Oct 2021

Introduction/welcome

<scribe> scribe:bruce_bailey

reminder to sign up for scribing

SLH: wiki page being refreshed

CDV discussion

AndySomer has discussion page on GitHub

<jon_avila_> https://github.com/w3c/low-vision-a11y-tf/discussions/121

AD: color blindness is misnomer

<Sam> How about colour impaired?

AD: gives the wrong impression

<Sam> +1 for not using colourblindness

CVD is clinical term

<Sam> Changing a familiar term to an acronym isn't ideal either though

<ChrisLoiselle> https://github.com/w3c/low-vision-a11y-tf/discussions/121

<AndySomers> yea do not want an acronym at all

AS: summarizes notes from GitHub discussion

Jon: as group, we can use terms we want to use
... limited color discrimination, etc.

<Sam> CVD is commonly cardiovascular disease!

Jon: after we decide, we will want to make our recommendations to the AG WG or Silver to ask for them to be consistant
... SLH mentions there is a color blindness community group, so communication is an issue

<Zakim> shawn, you wanted to note not only in IRC please

<jon_avila_> q

AS: I have tried socializing "color limited" , SLH did not care

SLH: please make point to get on queue to vocalize anything in IRC

JonAvila: Yes, it is easy to miss IRC, so please speak up

<jon_avila_> q

<Bhoomika> Could we say something like Low Color Perception

Sam: Noted, will use queue

JonA: Please ask around, make suggestion to GitHub discussion

<ChrisLoiselle> https://www.w3.org/TR/low-vision-needs/#color-vision is worth reading when discussing this proposed phrasing change

SLH: I would like to talk to people who have color vision defects, come back to this

JonA: In my experience, but I am not color blind, but folks with "color blindness" feel misunderstandings

Jon: So I see people use grayscale to test, and testers tend to think that helps "color blindness" when it is just a testing tool

Andy: There are some simulators that give the CVD person *more* colorful images
... I used the term "ableist" so it is important to talk through

<AndySomers> Also for examples, my CVD simulator at:

<AndySomers> https://www.myndex.com/CVD/

<jon_avila_> q

ChrisL: please see link [in IRC] for some notes terms

<ChrisLoiselle> https://www.w3.org/TR/low-vision-needs/#color-vision

<jon_avila_> q

JonA: It would be good for us to promote colorful filtering tool , help move away from greyscale

Jon: Please think about it, bring up in future meetings
... add thoughts to GitHub discussion page

Font-x-size

Andy: This came out of SAPC research

<jon_avila_> https://github.com/w3c/low-vision-a11y-tf/discussions/118

Andy: shared with Janinia S at APA just before Covid hit
... see link for discussion
... idea is set font size by X height , a CSS propert
... default font size is jut not sufficient

JonA: As I understand the core of the problem , 14 pt is just does not mean what people expect

Andy: exactly, a 12px (css) might be as small as 6 point and as large as 14 point -- so almost 100% range difference

<jon_avila_> q

Andy: didn't seem to problem in print world, but on the web, with so much dynamic, just huge difference

<jon_avila_> q

Sam: Yes, huge issue. Almost as bad as font weight.

<jon_avila_> q

Sam: font weight 400 meanless for comparing one font family to another
... some fonts have very large x height , as compared to body weight
... line spacing also is a similar confounding problem

<jon_avila_> q

Sam: and all authors have to work from is font size, but that is not telling enough

Andy: Agreed, not one property, but font x height is key, other properties follow
... my proposal touches on all these

<jon_avila_> https://github.com/w3c/low-vision-a11y-tf/discussions/118

<AndySomers> Link to CSS x-height standard

<AndySomers> https://github.com/w3c/csswg-drafts/issues/6709

Font-x-size property for CSS

JonA: Redefinign CSS to include x height is a heavy lift, is there a work around?
... can we specify something else in a11y standard in iterium

<jon_avila_> q

AndyS: We did have some discussion about font equivants, picking a good match from a list
... hard to fix without this being a CSS property

<ChrisLoiselle> https://www.w3.org/Style/CSS/ and more importantly , https://www.w3.org/Style/CSS/all-properties.en.html are references for current properties. More information , https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#propdef-font-size and https://www.w3.org/TR/2021/WD-css-fonts-4-20210729/#propdef-font-size are all useful resources on this topic

Sam: How long would this take? One thing for propert, then browsers need to pick that up.

<jon_avila_> q

Sam: there would be work-arounds in the mean time

Andy: This has been a problem since the beginning.

<shawn> +1 that it will take a long time to get in CSS and get implemented in browsers

<jon_avila_> q

Andy: long term on-going problem, there is a "can i use this" website

AS: This topic, font x size, is a reason on its own for this group exisiting
... CSS level 4 is late in development cycle
... this is the kind of thing that browser might adopt it
... browser developers are open source, so it might not be five years

<jon_avila_> q

Chrisl: links above for font size and font modules

<ChrisLoiselle> https://github.com/w3c/csswg-drafts/labels/css-fonts-4 provides the ability to log issues, https://github.com/w3c/csswg-drafts/labels/css-fonts-4

Chrisl: those are reference points

<shawn> Bruce: convinced very important. don't know path to get in front of right people. AG not voice to get it done?

<shawn> ... help to get overall AG behind it?

<shawn> ... call it done. don't think this group needs to debate it anymore.

AS: css working group does have some movement
... i am try tying to suppor the community actities , they are new to me , and I am new to them

<Zakim> shawn, you wanted to note purpose of this group and to note browser adoption

AS: i am also trying to coordinate with APA

SLH: APA Chairs Janina (pronouned Yanina) & Becky Gibson
... change takes a while

AS: Understood, x height motivated me, but that is not why LVTF restarted up

Sam: Agree x height is important, and properly domain of CSS, but we could figure out a JavaScript oriented API to demo
... So we could publish and ugly patch as proof of concept.
... we can write the guidence we would like to see.

AS: Best approach might not be API and JavaScript, but at least FireFox has exposed some utilities
... just there browser, but one reasonable proof of concept

JonA: I am see a few multiple paths for us to pursue.
... We agree on the need, agree on one approach.
... we can make a recomendation to AG WG
... but AG WG does not own this space either, but AG WG can make recommendation to APA , and APA can communicate to CSS WG

AG WG does not have control on those specifications , so AGWG not in possition to drive that activity

<AndySomers> Understand bandwidth...

AS: Please looks at those open issues though, all you need is a GitHub account

SLH: All for raising awareness , this seems to be issue of bandwidth rather than management
... Please include short summaries in those GitHub issues and disscussions
... blocker is not politics, limitation is band width

<Zakim> shawn, you wanted to note bandwidth over politics

AS: I have tried to start issues with shorter over view , technical details in subsequent threads and posts

<AndySomers> THANK YOU ALL for discussinghtis

<AndySomers> this

JonA: We might be able to speak with APA on how to communicate with them.

Sam: Can we write our guidence regardless?

JonA: We can define our terms, agnostic to the implementation.
... so we just talk about x height , leave implementation details to other

Andy: x height is long respected term in print , so that should be fine

Supplemental Guidance

Jon Availa: We put together this large table , even though they are all releated , makes it difficult for people to get started.

scribe: smaller items can be part of a theme of large issues.

SamWaller: I like to walk through word document
... in Word document , each table separt group
... just body text and spot reading for now
... my word table topics only looked at those two grouping
... understand that we want smaller bits
... my take is body paragraph text might be easier for first pass
... can say a few very certain simple things: basically size and contrast

Trickier is spot reading , since might have very good reasons for low contrast icons or whatever

scribe: for spot reading there are extra confounding issues , some are in tension
... i did try working with SAPC tool , which does have caveats around font choice being used for symbols or body text.

JonA pauses for questions.

AndyS: Agree that this aligns with much of the work I have been doing. Body text versus columns of text may be one term to work through.
... agree that color is much significant for body text.

SLH: I think the main topic of discussion for today is how to organize our work.

AndyS: I am not sure about utility for separting out body text from spot reading.
... I like small topic, but I want to know how to expand.

JonA: Does a grouping for body text make sense?
... guidence might be end up being redundant
... for example, break up requirements for body versus spot as opposed to contrast , then having body and spot underneath this

Andy: Many things will need similar requirements
... readability is the the most important thing , but there will be other issues that overlap

ChrisL: [to Sam] what about footnotes and logos, which category does that got into

Sam: It does come up, but think copyright and subscripts

AS: I ended up with four "buckets"

ChrisL: with some of our earlier writing we kept mentioning body text in other guidence

<shawn> Template for Low Vision Supplemental Guidance https://deploy-preview-21--wai-wcag-supplemental.netlify.app/lv/template/

ChrisL: context in brief description

<Zakim> shawn, you wanted to say 1. body text, 2. spot text, 3. background for both!

SLH: Supplemental Guidence hat: template has section for "How it Helps". if too repetative in multiple supplemental guidance docs, then put elsewhere and point to.

maybe one major section is body text and another is spot ready

spot reading

SamW: We have two proposals here: one is contrast / size / padding
... the other way is body text , then spot as second group

body text could be short

prose for spot reading gets so much more complicated and involved , like SAPC tool or step thresholds

scribe: works for menu and else

<Zakim> bruce_bailey, you wanted to say i like focusing on body text first

<shawn> Bruce: loving the idea of starting out with body text. since not regulatory langauge, don't have to be tto strickt, e.g., don't have to have formal defintinios of "body text"

<shawn> .. then can come back to the hard things

Bhoomika: Want to separated out these topics and subjects..

<AndySomers> This is more complete: (long):

<AndySomers> (A) Fluent Readability[edit]

<AndySomers> Columns of body text (body text has elevated requirements for best score)

<AndySomers> Headlines, Subheads, Asides

<AndySomers> Primary navigation, Primary menus

<AndySomers> Descriptive captions that convey meaning beyond the image.

<AndySomers> Font weight and size are interdependent with luminance contrast.

Bhoomika: very difficult to navigate with screen reading sofwares at the moment.

<AndySomers> (B) Spot Reading Level[edit]

<AndySomers> Copyright, ByLine, and Legal Notices and links thereto (secondary navigation).

<AndySomers> Captions that only restate the captioned item or provide only credits, byline, rights, etc.

<AndySomers> Ancillary text that is not a part of, nor critical to the understanding of, the primary content.

<AndySomers> (C) Non-Text Elements[edit]

<AndySomers> This means buttons, controls, form fields, clickable objects but does NOT apply to any text within these items.

<AndySomers> This also includes temporal/spatial state changes (including state changes to text, which is necessarily separated from the text's readability contrast).

<AndySomers> Contrasts within an image or drawing that is part of content.

<AndySomers> Contrasts in size, shape, temporal, and spatial relationships are often interdependent with luminance contrast.

<AndySomers> (UX) Aesthetic Contrast[edit]

<AndySomers> Simply anything that is purely decorative, non-readable, not needed for understanding content.

Bhoomika: I will also suggest adding screen shots, my colleagues find those helpful

<AndySomers> It can include contrasts that may be helpful for organizing content but are not strictly necessary.

<AndySomers> These have no standard other than to not distract nor interfere with use cases A, B, and C

<AndySomers> Sorry pasted the text instead of link OOPS

<AndySomers> link https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup#Use_Cases_Defined

JonA: Agreed with all those points, make simplier to use, add examples, maybe add additional icons.

ChrisL: I will suggest "applies to" style

<ChrisLoiselle> https://www.w3.org/TR/2021/WD-css-fonts-4-20210729/#font-size-adjust-prop

JonA: My own opinion is that body text focus seems reasonable way to work at first

ChrisL: CSS docs have "applies to" and "brief description" to help figure out where properties are applicable.

<shawn> +1 for the table that Chris and Jon define

<AndySomers> 1. Fluent Readability Contrast

<AndySomers> Contrast for Spot Reading

<AndySomers> Contrast for non-text objects, images, elements, states (focus), etc.

<AndySomers> Purely aesthetic Contrasts.

JonA: We can list things a couple ways, so sort by Font Weight and Contrast -- and see detailed description
... but another sort is by body text and spot reading

<AndySomers> Fluent readability includes body text BUT ALSO includes other content text.

JonA: depend who is reading, developer or content author

SamW: I just want to mention that some of my defination not totally aligned with AndyN -- for example menus need to be fluid or not?

<AndySomers> Multiple lines of text is body, with the highest contrast needs due to spatial frequency

SamW: Is a copywrite disclaimer body text or spot reading ?

<AndySomers> less than blocks or body is content text that is NOT spot reading

<AndySomers> Spot reading is for text that is non- important.

<AndySomers> Body text is defined as more than two lines in a column of block

JonA: Talking about "a line" is not meaningful for low vision when magnification is high.

SamW: Take advantage that this is supplemental guidence.

<AndySomers> SPOT reading is allo2wed to be less that the CRITICAL size and contrast, but OTHER FLUENT CONTENT is NOT.

<shawn> +1 for not cluttering the supplemental guidance with specific definition of body text!

JonA: We have not figured out how to split out some of these, some are more interrelated.

<AndySomers> The DEFINITION of body text is ONE LINE:

<AndySomers> Body text is defined as more than two lines in a column of block

I wanted to walk people through what would be a good process.

Process for Supplemental Guidance

* build on discussion pages

* add issues

* make draft github page

* more discuss

* add to meeting agenday

SamW: still have some logistic issue

SLH: will circle back with Sam

Chris: I looped in Michael Cooper

SLH: please make some notes and share, we will work out permissions

<ChrisLoiselle> Bruce: Could you point us to the list of items ?

<Zakim> bruce_bailey, you wanted to ask for that outline on wiki or whatever

<jon_avila_> Agenda items: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/LVTF_Meetings

<ChrisLoiselle> Jon: It is on the wiki meeting page to review.

JonA: Are people okay with signing up ?

SLH: Can't be asking people to edit HTML table.

JonA: Meant to ask if folks are okay with broad outlines of process ?

AndyS: I am not content with "spot reading" as category -- different than fluid reading

JonA: Can we have other categories.

<ChrisLoiselle> Could we reference https://w3c.github.io/html-aria/#el-body and reference the html element?

<shawn> Bruce: Let's do body text now. Don't bother with defining it. They we can figure out everything else later.

Andy: SAPC focus has been on "fluent reading"

<jon_avila_> trackbot, list attendees

<trackbot> Sorry, jon_avila_, I don't understand 'trackbot, list attendees'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<ChrisLoiselle> Reference point on grouping , didn't discuss on call https://html.spec.whatwg.org/multipage/dom.html#kinds-of-content

<ChrisLoiselle> perhaps grouping in this way?

JonA: please consider signing up for small topics

SamWaller email with Word attachments is here:

https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2021Oct/0000.html

- DRAFT -

Low Vision Accessibility Task Force Teleconference

07 Oct 2021

Attendees

Contents

Introduction/welcome

CDV discussion

Font-x-size

Supplemental Guidance

Process for Supplemental Guidance

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output