Meeting minutes
<jamesn> recording the presentation portion of the meeting so no scribing for this part
<jcraig> link for the two GitHub issues mentioned?
<jamesn> https://
<jamesn> https://
<jcraig> aaronlev: chrome 89 reads base text.
aaronlev: Are there any cases where you would want to just read the base text?
murata: 20% of the time (for interlinear nodes), read both
murata: other 80% read only base text
aaronlev: why not text above, <rt>, if it has more pronunciation info?
<jamesn> link to slides - https://
murata: reading phonetic ruby can be dangerous
jcraig: agrees with fantasai about exploring native html attribute, e.g. <rt type="phonetic"> or similar
jcraig: would missing attribute be sufficient to assume the inverse value?
jcraig: or should missing me undefined, and a guess would be best
MURATA: have not analyzed best approach
MURATA: do not yet have opinion on this question
jcraig: in ARIA this might be something like aria-use-for-pronunciation
jcraig: it feels like it should be a native attribute
jamesn: would you expect something different to be exposed to ATs based on the semantic?
jamesn: how is Braille affected
MURATA: in the case of non-phonetic ruby, the AX tree should have both texts
jamesn: the primary use is for different TTS rather than different meaning
MURATA: i just need a standard mechanism
jamesn: not sure role is correct, i recommend an html attribute
<cyns> +1 to html attribute
aaronlev: chrome uses aria-details, which puts control in users hands today
aaronlev: we could use role="note" on <rt> to indicate it's non-phonetic, and this seems to be sensible in a semantic sense
<jcraig> Ruby for the speaker https://
juanita: joining late, gets description of the different types of ruby, asks about how the role="note" markup would work
jcraig: wanted to respond to Murata's comment that the ruby phonetic distinction should be exposed in the accessibility tree
jcraig: regardless of whether this is a native Ruby attribute or ARIA, it will need be exposed in the accessibility APIs
(jcraig do i have that right?)
jcraig: so would the semantic *only* be useful for accessibility? that's a key difference between ARIA and native markup -- ARIA is only exposed to assistive technology, and is not used for mainstream display differences like Murata is suggesting such as hiding the "para" pronunciation hints by default
jcraig: if it's useful for anything else I think it would be clear that it shouldn't be ARIA
<Zakim> jcraig, you wanted to respond to "accessibility tree should display the phonetic difference"
MURATA: have not thought of or found any non-a11y use for the semantic
MURATA: planning to publish wiki article as a W3C note
<Zakim> jamesn, you wanted to ask if there is ever a case to ONLY read the ruby
<MURATA> GIKUN
jamesn: obviously there are missing semantics, maybe there should be a different element, or an attribute
jcraig: i don't think it needs to be a different element
<cyns> <rt type="para"> (default), <rt type="gikun">, <rt type="general">
jamesn: if it's native it has a much higher likelihood of author use
jcraig: agree
<jcraig> aaronlev: user can decide in chrome whether to speak ruby base, ruby annotations, or both
<jcraig> aaronlev: exposing the semantics for user choice should be the first priority, right?
<Zakim> cyns, you wanted to ask if color coding of phonetic vs. non-phonetic for language learners might be a use case
cyns: i put some suggestions above
cyns: agree screen reader should have heuristics to be able to try to guess which to use, as a repair
<Zakim> jcraig, you wanted to clarify 1619 vs 1620 and to respond to aaron's comment and to consider in the context of the ssml/pronunciation topics earlier
<aaronlev> pronunciation, pronunciation-advanced, note
<aaronlev> pronunciation-learners, pronunciation-advanced, note
James: We have this ongoing pronunciation conversation. Someone suggested we use Ruby for this. To clarify 16.20 to 16.19 this is effectively one issue. We need more semantics in Ruby because there are multiple meanings. Some our pronunciation-related and some are accessibility related.
… 16.19 is about displaying those two cases
<Zakim> jamesn, you wanted to respond as to why they are different issues
James: I believe is purely for visual display changes. You should not read the pronunciation hint. The other is which meaning to read -- or both
… if we do something in HTML, we'll need to provide something in ARIA
James: Ruby is for phonetics, but this usage is not phonetic. Both are phonetics, but one is not displayed.
<aaronlev> type="phonetics-learners" | "phonetics-advanced" | "note"
JamesN: If you pronounce the phonetics, you get an incorrect pronunciation.
<jcraig> ruby rendering is well supported
JamesC: Ruby is reasonably supported in browsers and really common in Japanese books. Ruby accessibility is not as well supported
cyns: There may be a fallback use case as well
<Zakim> cyns, you wanted to ask if there might be a case where a tts doesn't know the katakana and would need to use the phonetic ruby as a fallback?
JamesC: We need to respond to the issue and ultimately close it once it's pointed to a new tracker in HTML or DPUB
JamesN: (Topic change) Re: IDL we need a way forward for 1.2.
https://github.com/w3c/aria/issues/1598
jamesn: when we published aria 1.2 draft, we published based on changes requested from various folks in HTML WG - that there was no such thing as nullable strings in HTML. In testing we learned that there are nullable DOM strings and not vice versa... we believe that is actually what we want, so we are in a strange dilema
jamesn: we're in a strange situation where we have reverted the spec and we have implementations that are different. We are at an impasse at where we should go to make everyone happy
jamesn: does anyone want to clarify more
jcraig: Annvk and domenic denicola were objecting to the pull request, and said they would attend today... cyns had reached out to domenic, and I'm not sure where that stands right now... unfortunately she's not able to discuss right now as she's in the car
<jamesn> “If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is in its missing value default state then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value
<jamesn> in a transparent, case-preserving manner.”
<jamesn> https://
jamesn: this is where HTML defines how to reflect various kinds of values in attributes
jcraig: I'm unsure the experience of others on the call and their experience in IDL - anyone on who can help advise us here?
gregwhitworth: I haven't kept up with this unfortunately
gc: we debated long and hard - we actually went back and forth between the two. I will go back and look more and we will comment on the issues...
gc: I forgot what we landed on, but I will try to dig up notes and add 2c
jcraig: do you have an implemented nullable reflected string?
gc: we have .... something.
gc: in lightning web components we do something internal in salesforce - I remember hitting this issue and it leading to lots of discussion
jamesn: I guess we should wait for cyns on this and move on for now
<jamesn> https://
jamesn: apologies to folks, we were really hoping to get this unblocked because it is the issue that is holding us up... would be really happy to hear any other ideas about how we get past this, otherwise we can move on
cyns: I have a draft in a google doc, I will share it here in the presentation but I dont want it minuted because it is temporary and won't continue to exist...
cyns: I took the text from alice's pr and modified ita bit... it has gona on a whole lot
cyns: I think there were _hundreds_ of comments on the issue, many meetings
cyns: the majority were around sprouting attributes...
cyns: the concern with 'sprouting' is that if you were to say it sprouts an attribute, there were a lot of bad options. the least bad was to not reflect in that direction - to not change the DOM attribute. It's a little complicated - the main downside of this approach is that the DOM in the inspector could be out of sync in some cases
(cyns presents)
jcraig: just to make sure it is clear - when cyns described DOM as being out of sync -- nothing is really out of sync, but web authors inspecting the DOM can't see it as clearly by existing norms, as a content attribute... it's kind of "partial reflection" or "one way reflection" to some degree
cyns: indeed, it is a little complicated, but I dont think it is much of a problem in practice. we will probably have to provide author advice -- here we're focused on the HTML spec which is very implementer focused
jamesn: it's complicated. I'm actually going to step back to the previous part... do you think this is what they are looking for - for the nullable thing?
cyns: yes
jamesn: where can I find that in the spec?
cyns: this text would be added to section 2.6 of the specification
cyns: we would need to add something similar for how null behaves.
cyns: I can take on writing that, but probably not until next month - if someone wants to volunteer because they want to move it sooner, they can
jamesn: I don't see this for all of the standard types though?
gregwhitworth: question about the 1-dimensional reflection... are there use cases that we lose besides the developer inspection of the dom
cyns: not that I remember... triple equals doesn't work in some cases, but we decided together that was probably ok
gregwhitworth: but there aren't author use cases that we can think of that fall off the table...?
jcraig: maybe we could step back and give an example of why this couldn't be reflected. one of the main examples of this is we can't give an idref between documents, like pointed inward in a shadow dom context
jcraig: so there's no way to reflect that in the DOM
cyns: are there cases where you have labels inside of a shadow dom?
<jcraig> aria-activedescendant etc too
gc: labels inside a shadow dom... we're looking at this as a per-component basis, so far there is some element outside the shadow which will want to link into the button
gc: we have things to figure out how to do it
cyns: something we've been talking about AOM discussions is whether we can have a name calculation that allows you to reference that
gc: thinking outloud... like with slots, they aren't actually 'moved in', they continue to exist in the light dom, we just create linkage.... maybe we can draw inspiration from that
cyns: another use case we talked about is being able to apply attributes to a custom element and determine which of those things that goes to, that is a lot more like slots
cyns: but this is all "down"... we've not discussed how to go out of the shadow, if there is a reason to expose something on the container from inside
gregwhitworth: on that I dont know why we wouldn't just use name calculation rules
cyns: those are pretty complicated, I'm not sure if someone on the call wants to comment
gregwhitworth: that's why I don't want authors creating their own computed name due to its complexity. We should just have an API on shadowRoot or something that returns the computed name for the shadow I (?)
cyns: how hard would it be to calculate the name of that shadow dom as if it were a whole document and present a way that the outside could use it
jcraig: this is a topic we've discussed for many many hours in AOM meetings and in other places... I think we had talked about a way for the component owner to do that as a property of the shadow rather than have the engine try to infer what the label should be ... I hesitate to try to dig into this more here and speculate at another solution during this call since many of the engaged implementing engineers aren't in attendance
cyns: having the author do it is also not without downside
aaronlev: was the question whether work this should be on the engine side or on the author side?
jamesn: It seems we need to fix attname for shadow roots anyway... at that point, sure why wouldn't you expose it on the component... it seems like a reasonable thing to do
cyns: I think we have been avoiding ti, because it is hard
jamesn: it kind of works in browsers, we have to write down what we are doing
aaronlev: are we talking about when is aria labelled by pointing from one side of the shadow to the other? there is no format for ids that allow that
aaronlev: random idea - there are chars that aren't allowed in IDs, we could use those maybe to make some way to do it
jamesn: if I reference a component with an idref, then nothing gets returned?
aaronlev: not inside the shadow content
jamesn: but just the web component itself
<gregwhitworth> <div aria-labeledby="foo"></div><custom-element id="foo"></custom-element>
cyns: the equivalent of pointing to an iframe element
aaronlev: so can we walk in from there?
jamesn: in dev tools, it does seem to walk down into the thing, I'm just not sure
aaronlev: yes, it can walk down through the AX objects, if we have a computed name we expose it might be leaking information we probably shouldn't be
<gregwhitworth> <div aria-labeledby="foo"></div><custom-element><div id="foo"></div></custom-element>
<gregwhitworth> is what aaronlev is saying won't work
cyns: it might accidentally work in a way that is breaking shadow boundaaries
aaronlev: it's not the only use case though, right - we need to point both ways, right?
<gregwhitworth> bkardell_: I was on the queue a while back and I wanted to reiterate here that there have been a ton of discussions on these topics
<gregwhitworth> bkardell_: most people have trouble keeping up with where we are now
<gregwhitworth> bkardell_: we shouldn't try to solve here
<gregwhitworth> bkardell_: maybe some of us should produce a consumable summary and weigh in with what has already happened, been shot down, etc
<gregwhitworth> bkardell_: I recall there was a proposal and there was an import/export idea to express this
<gregwhitworth> bkardell_: a lot of idea
cyns: yeah - so the two things we have concensus on are these two things in the agenda... not sprouting in these cases, and to allow you to put aria on the custom element and have a way to tie that to a paricular elemenet in a shadow root
cyns: I think that one seems pretty straightfoward and uncontroversial
cyns: how do people feel about the lack of content attribute synchronizing?
Jory: would this cause problems with testing tools?
jcraig: it is available, testing tools can use it - but if they make assumptions that are only in the DOM as content attributes that won't be accurate alone
<jcraig> bkardell_: is available, but as a new feature
<jcraig> bkardell_: none of the testing tools are perfect. they all have false positives and false negatives.
cyns: some examples would be helpful I think
<jcraig> bkardell_: calling out the false results will help expose the shortcomings of the testing tools and could help with the resolution
cyns: are there other things that would be useful beyond seeing examples and what the input and output is
gregwhitworth: examples would be very helpful, yes
jamesn: this code (on the screen) is destined for the HTML spec?
cyns: yes
gregwhitworth: since I think ultimately the goal is to land - is what you are showing here the solution to bi-directional references?
cyns: I think it is the best of all of the bad options
gregwhitworth: our team at salesforce will review it if you send this to the list with examples, as you suggested, and get feedback
<jcraig> thanks for attending gregwhitworth
<jcraig> FYI Dominic just responded at https://
<jamesn> revised proposal? "If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is missing then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value in a
<jamesn> transparent, case-preserving manner.”
<jamesn> revised proposal? "If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is not present then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value in a
<jamesn> transparent, case-preserving manner.”
bkardell_: I laid that out in order to better understand whether you thought maybe we were doing things we shoudn't right now, or not doing things right now we should
<cyns> https://