<scribe> scribe: becka11y
Janina: any new topics?
Joanie: I have a CSS issue to bring up
Janina: is earlier in the year
for 2019; happening in South of Japan; expect to have APA
meetings; task forces are asking about participation; will be
developing an agenda. Who is able to show up will drive our
agenda
... will have soon have a page to develop ideas
<Zakim> joanie, you wanted to humbly request APA prefer Monday and Tuesday
Joanie: ARIA WG is planning on attending and have requested Thursday and Friday dates; many ARIA members belong to APA as well and requesting that APA meetings happen earlier in the week so they can attend
Janina: Yes, agree will try to avoid clashing with ARIA wrt meeting times
JF: AG WG call discussed this and are looking at meeting on Monday and Tuesday or perhaps Monday and Friday
Janina: Thanks for that info, please keep up informed of any updates. Also, Michael works with both AG and APA
JF: will not be attending TPAC this year - is getting married that week
group: Congratulations!
<joanie> https://github.com/w3c/csswg-drafts/issues/3745
Joanie: employer is working on implementing MathML in Chromium; colleague filed an issue about CSS text transform values for use with MathML
<joanie> Regarding the a11y issue, I believe a11y and CSS people should first agree on whether to expose the text-transform text as what the CSS spec says and the actual a11y implementations seem to differ.
<joanie> Joanie would like the CSS taskforce to work towards consensus on what screen readers should do in response to transformed text.
<joanie> Joanie feels that user agents should expose whatever the consensus is via the APIs' text interfaces so screen readers do the RightThing(tm)
Joanie: once we have consensus we need to browsers to all do the same thing so screen readers will also be consistent. But we need to resolve the differences between the CSS group and APA’s CSS task force
Janina: Need to involve the pronounciation task force; This goes beyond just screen readers - need to address read aloud options, etc
<joanie> Fantasai said: If AT is exposing these transformations when reading text aloud, this means we have no way to make these visual transformations without distorting the text for AT.
Janina: distorting is a value judgement;
Joanie: if you use CSS text
transform to captialize and element; the visual user will see
it as capticalized but a screen reader doesn’t get that
information
... it seems that CSS WG believe that screen readers should
expose what is in the DOM rather than what is visual exposed
(via CSS text transform)
Janina: I can’t understand why people believe that the screen readers should announce the DOM text and not announce the visuallly modified text
<Zakim> JF, you wanted to ask Joanie who should generate that consensus?
JF: Who should make this consensue? This seems to involve several groups. Should we involve Web Plat? Also, there is precedent that Screen readers are outputting CSS modified content - for example, display none and before and after
Irfan: if DOM is lowercase foo and CSS makes in FOO in uppercase - isn’t CSS just to style the content and NOT to change the behavior in the DOM?
JF: is AOM (accessibiity object model) involved?
Joanie: I don’t think so. This
started as an issue with MathML issue and branched out into
accessibility
... am asking the CSS task force to investigate this issue and
get all of the groups together to reach consensus on this
should work
Janina: there seems to be a scoping question here - who is developing specs that involve the voicing of content vs display of content
Irfan: this text transform can be used with other CSS properties and this will generate many use cases for the need to perhaps announce in different ways
Becka11y: another example is where someone uses CSS transform to make headings visually in upper case
Joanie: exactly, the issue how that should be exposed to the screen reader - the DOM entry or the transformed entry
JF: So who is responsible for working this issue?
Joanie: this seems to be an APA issue to drive this
Janina: Yes, we have a pronounciation task force and CSS task force so they should be responsible for providing guidance; Need to include our use cases for the pronounciation task force
Joanie: some aspects of CSS change what is in the accessibility tree. CSS group thinks it should not; The accessibiity people seem to believe it should. Need consensus on this - who is responsible?
Janina: I think JF pointed out that we need to be consistent throughout CSS
JF: need to go back to HTML principles of hierarchy of roles
Janina: I will make sure Ian gets
a pointer to this conversation and we (APA) need to discuss
further; I heard Joanie mention that perhaps this should be a
configuration issue and let the user decide;
... what are current newspaper headlines - how are they
presented visually?
JF: it seems to vary by content author. For example Huff Post captitalizes by typing in captital letters vs using css transforms
Joanie: for example: Orca just takes the text from the accessibility tree and announces it.
Janina: so then it wouldn’t matter how the user typed it in or it was transformed by CSS
Irfan: font face variations also come into play
Janina: has been a useful conversation; is there a particular deadline for resolving this?
Joanie: I don’t belive that there is but we need another venue for discussing this (rather than a convoluted github issue)
Janina: this shows that is it good for us to continue vocalizing that we have a pronounciation task force
Janina: our comment draft is
finished; they are hard to handle gracefully; we continue to
get interest with this rewrite;
... we did get comments from lead dev. of recaptch at
google
... we didn’t get any comments about a long section on
implementation that perhaps has security implication
... encourages the group to re-read the document so we are up
to date on these calls. We will need a second wide review draft
due to the number of comments
<janina> https://www.w3.org/WAI/APA/wiki/Category:Spec_Review_Not_Checked
<JF> https://www.w3.org/WAI/APA/wiki/CSS_Transforms_Module_Level_1
Janina: we will point Ian to this (CSS TF)
<JF> https://www.w3.org/WAI/APA/wiki/Trace_Context_Protocols_Registry
<JF> https://www.w3.org/WAI/APA/wiki/User_Timing_Level_3
JF: appears to be mechanical behind the scenes info via HTTP headers
Janina: agree we don’t need to
review this
... We might care do to the issue of fingerprinting - this
might be a way to identify a person with a disability
... We believe we forwarded a comment already and have gotten
no response so we need to reach out again
... any progress to report on open actions?
... any other business?
... thanks for good discussion and to Joanie for bringing
forward the CSS issue
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/ORCA/Orca/ Present: irfan janina Matthew_Atkinson Becka11y Joanmarie_Diggs Gottfried JF JonnyJames Regrets: Chris Found Scribe: becka11y Inferring ScribeNick: Becka11y Found Date: 27 Mar 2019 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]