<scribe> scribe:bruce_bailey
reminder to sign up for scribing
SLH: wiki page being refreshed
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
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
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.
* 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
This is scribe.perl Revision VERSION of 2020-12-31 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/misnomber/misnomer/ Succeeded: s/Becky Gibson and Yanina (not Janina from APA) so keep dialog/APA Chairs Janina (pronouned Yanina) & Becky Gibson/ Succeeded: s/Bruse:/Bruce:/ Succeeded: s|template has tabs / icons for organizing|template has section for "How it Helps". if too repetative in multiple supplemental guidance docs, then put elsewhere and point to.| Succeeded: s/for that table !/for the table that Chris and Jon define/ Succeeded: s/JohnA:/JonA:/ Succeeded: s/Michael Coooper/Michael Cooper/ Succeeded: s/Bruse: Let's do body text. Don't bother with dedining it. They we can figure out everything else alter./Bruce: Let's do body text now. Don't bother with defining it. They we can figure out everything else later./ Default Present: Andy, Shawn, AndySomers, ChrisLoiselle, Bhoomika, bruce_bailey, JonathanAvila, SamWaller Present: Shawn, AndySomers, ChrisLoiselle, Bhoomika, bruce_bailey, JonathanAvila, SamWaller Found Scribe: bruce_bailey Inferring ScribeNick: bruce_bailey WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 07 Oct 2021 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]