W3C

- DRAFT -

Accessible Platform Architectures Working Group Teleconference

27 Mar 2019

Attendees

Present
irfan, janina, Matthew_Atkinson, Becka11y, Joanmarie_Diggs, Gottfried, JF, JonnyJames
Regrets
Chris
Chair
janina
Scribe
becka11y

Contents


<scribe> scribe: becka11y

Agenda Review & Announcements

Janina: any new topics?

Joanie: I have a CSS issue to bring up

TPAC 2019

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!

Task Force Updates

<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

CAPTCHA Note Update

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

new on TR http://www.w3.org/TR/tr-status-drafts.html

<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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/03/27 16:56:49 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]