– DRAFT –
ARIA WG

carmacleod: are we ready to start discussing evergreen?

carmcleod: at the moment there is an issue but nothing in it

<MichaelC> https://www.w3.org/2020/Process-20200915/

<jcraig> Cooper: iii-iiiiiii-aaaaaaaaaa-aaaaaaahhhhh

MichaelC: I don't think w3c has a specific guidance for that. The process doc has part of that and there might be a wiki page

jamesn: anyone think we shouldn't talk about this in a deep dive?

<MichaelC> https://www.w3.org/wiki/Evergreen_Standards

<MichaelC> https://www.w3.org/wiki/Process2020

jamesn: is there anyone who has gone through this before that we could speak with?

MichaelC: I think css has gone through this

jamesn: if we're ready to discuss this by tuesday then we can deep dive it

jamesn: anyone want to suggest a backup?

jcraig: we start with aam that moves to evergreen

jamesn: I think we already decided that

jamesn: working groups have already discussed that actually

jcraig: maybe the next step is to get through that process of moving AAM, so then the discussion will be more informed

MichaelC: everyone will get booted out of the group and rejoin

carmacleod: I agree that we should go through the AAM first

carmacleod: what about html-aria?

jamesn: html-aam is an on the rec track. I assume anyone who uses it looks at the editor's draft

<jcraig> Here's the AAM issue... https://github.com/w3c/core-aam/issues/81 I recalled an earlier one but no matter.

MichaelC: I think we need to kick off some work here

MichaelC: We've never sat down and said "ok this is our work plan"

jamesn: It sounds like we have a topic for a deep dive -- how are we going to implement this evergreen plan

AccName<https://lists.w3.org/Archives/Public/public-aria/2021Jan/0052.html>

jamesn: bryan sent out a message asking for clarification on some accName questions. I propose we talk about them here to make sure we're all on a similar page

<jamesn> <div id="p">

<jamesn> <button id="test" aria-labelledby="p" >Screen Text</button>

<jamesn> </div>

jamesn: what would you expect the accessible name to be?

jamesn: myself and joanie came to an agreement on it being "Screen text"

jcraig: because the div is ambiguous as to the role, it is not clear if contents is included in that context. it's not clear if the name gets bubbled back up to that context

jcraig: the labelledby refers to an empty string

<siri> what scenario will this be used?

<jamesn> Otherwise, if the current node's role allows name from content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML), or is a descendant of a native host language text alternative element:

Bryan: the reason I put that one in there, if you look at chrome, it has no label

jamesn: Firefox and safari agree though

Bryan: all of these examples have ambiguities on what is meant by self-referencing

jamesn: which part of the spec are you referring to when you say "self-referencing"?

jamesn: where is that in the spec language

<jamesn> https://www.w3.org/TR/accname-1.2/

jcraig: I'm having a little trouble following 2e/2f

jcraig: the lettering/numbering is no longer there in the editor's draft

<carmacleod> https://www.w3.org/TR/accname-1.2/#step2F

jcraig: the accumulated text doesn't include the contents, right?

jcraig: because it says "if its referenced by aria-labelledby" and it says to include the child nodes...yea I agree

Bryan: self referencing is something causing some sort of loop to occur

Bryan: like you said (jamesn), it's not defined anywhere

<carmacleod> second example:

<carmacleod> <div id="p"> <button id="test" aria-labelledby="p" >Screen Text</button> </div>

jcraig: last year webdriver added computedRole/computedLabel. I don't recall if it's implemented in any of the rendering engines yet

jcraig: writing some Web Platform Tests (WPT) using WebDriver computedLabel for this would allow us to get an automated report on what is working and what is not

jcraig: the algorithm is getting so complex. that explains why there are different implementation for it. Automation is the path forward

Bryan: in this case, I'm just trying to figure out what should be happening. I can't move forward until we settle this

Bryan: button does support a value

jamesn: one wouldn't expect that to be shown to a user

jamesn: I think we have a typo in the spec regarding value

jamesn: they were intending to talk about menubutton not button

Bryan: if you have a collection of radio buttons you don't want to return the value, you want the human readable text to be returned

Bryan: form field and widget are used interchangeably in accName

jamesn: we don't use the term form field in it at all though

Bryan: but it still has to work with form field

Bryan: what happens if we have an aria-labelledby attribute which references the parent element and that same element (self)

<carmacleod> third example, with 2 different self-referencing processes:

jamesn: this one is slightly more difficult

<carmacleod> <div id="p"> <i id="q">Outside Text</i> <button id="test" aria-labelledby="p q" >Screen Text</button> </div>

jamesn: can aria-labelledby reference the same element multiple times?

jamesn: like <button aria-labelledby="q q q">...

Stefan: it's an authoring error

jamesn: should this be forbidden?

<jamesn> <h1>Files</h1>

<jamesn> <ul>

<jamesn> <li>

<jamesn> <a id="file_row1" href="./files/Documentation.pdf">Documentation.pdf</a>

<jamesn> <span role="button" tabindex="0" id="del_row1" aria-label="Delete" aria-labelledby="del_row1 file_row1"></span>

<jamesn> </li>

<jamesn> <li>

<jamesn> <a id="file_row2" href="./files/HolidayLetter.pdf">HolidayLetter.pdf</a>

<jamesn> <span role="button" tabindex="0" id="del_row2" aria-label="Delete" aria-labelledby="del_row2 file_row2"></span>

<jamesn> </li>

Bryan: if you follow the logic that they should all be included, then you'll get repetitive text. Your example isn't going to work (the delete button example #2)

<jamesn> </ul>

Bryan: I need someone to reply to my email with what is expected

jamesn: can people take a task to reply to the email? Adding a brief "why" would be useful as well.

<jamesn> https://lists.w3.org/Archives/Public/public-aria/2021Jan/0052.html

Follow-up: tree inclusion of focusable elements from #1100<https://github.com/w3c/aria/issues/1381>

<pkra> have to drop off early -bye, everyone.

jcraig: I actually thought that this was going to be a non-issue. But the issue is that we recently started implementing a webkit change based on some spec language change that was discussed with the group. The change is that we are going to include things in the accessibility tree at all times if they are focusable, rather than just when they are focused.

jcraig: So we started implementing this in webkit which broke a bunch of layout tests which was expected. So the engineer asked me to go back and confirm this change.

jcraig: This is why I created this ticket

jcraig: in the long term, inert is the right path forward

jcraig: webkit hasn't implemented inert yet

jcraig: bryan objected last week to this change because it was going to cause some points of confusion for users

Bryan: my colleagues were saying that a lot of the implementations that exist in the wild, especially modal dialogs, rely on the ability to hide background content so the users perception doesn't get distracted by the background content. The solution is to add aria-hidden to the background content and this is going to break that.

jcraig: the plus side to this change is that, right now there are some implementations of those modals that are broken. This would circumvent that problem. But as Bryan said this could cause problems/confusion

Bryan: on talkback if you swipe forward you couldn't interact with any of the background content but if you swiped backwards you could. So the user could tab all they want on the stuff that was slightly visible. But the AT user could actually interact with the background form fields and got stuck there

<Zakim> jamesn, you wanted to ask about aria-modal support

jcraig: I see 2 potential paths forward: One would be to just wait for consistent implementation of inert (and backing out this change). The other would be to potentially make an exception to this rule where it is not just anything focusable but is instead anything focusable when there is no modal state on the page.

Bryan: I do think that inert should be its own solution. I think that is a good way forward. I also see a value in differentiating between aria-modal and not aria-modal

Bryan: we do need some sort of differentiation between modal and non-modal

jcraig: one example that came up was a close button (for a dialog) being outside of the actual modal

jcraig: at least one of the windows platforms have a way to put an element in the tree but mark it as hidden. In case the AT needed to get to it for whatever reason. We've never had that in the iOS platforms.

<joanie> That's possible in ATK/AT-SPI2, but Orca treats things which claim to be "hidden" as not there.

carmacleod: I'd go with whatever the user agents want