Meeting minutes
New PR Triage
rahim: tallked to scott. we agree abbr[title] should not contribute to accname
is there any objection to it being announced on demand? should map to something that can allow the expansion to be announced on demand.
matt: how would you know, since we don't spec AT behaviors
matt: whether it's on demand or automatically is dependent on context
in some scenarios, it might be automatic on longer descriptoin a form fields
Adam_Page: in aria-practices, APG issue pattern date picker has abbreviated representations of weekdays, e.g. Tuesday for Tuesday.
Adam_Page: would like abbr[title] and th[abbr] to behave similarly
<Rahim> I do see an html-aam mapping for `abbr` (the attribute): https://
Adam_Page: another more complex example about buttons in header cells
jamesn: interesting that we're talking about exposing title on abbr for SRs, but keyboard users can't get it by default. what's the point in patching?
jcraig: the goal to make this exposed to platform APIs I can’t imagine it would be objectionable
Daniel: abbr attr support is lacking?
Daniel: would not get the expansion... "Tu"
<Zakim> Daniel, you wanted to say support for the abbr attribute is little
giacomo-petri: in addition to keyboard users, people with cognitive disabilities could benefit
Matt_King: PR is available to review
Matt_King: we don't need prose in the PR right? we just add the table mapping
Rahim: yes... need platform mappings, not prose.
Rahim: is it desirable to add a note or comment for existing abbr[title] to avoid using it for accname?
<Zakim> jcraig, you wanted to talk about verbosity
spectranaut_: maybe for the ARIA spec, not AAM
WPT Open PRs
Blocked by ARIA PR w3c/
rahim: web-platform-tests/
TPAC Planning
spectranaut_: TPAC candidate topics
Matt_King: for issues not tied to a spec, do you still want an issue?
spectranaut_: yes, with F2FCandidate label
jamesn: TPAC is a group driven agenda
feat: aria-actions addition to the ARIA spec
<front-endian-jane> Small comment back on PR 2237: there are some open comments/questions on it which haven't been responded to. Happy to review again when there is something to review again!
sarah: I reached out to Jocelyn recently, and chatted with Edge — they might have cycles coming up to work on it, but need Chrome update
… I’ll email folks
spectranaut_: we need to button up reviews
Matt_King: we had some discussion at TPAC last year
… especially inheritance
… actions on multiple things in the tree
… there were a lot of unanswered aspects in the PR
… did we get to resolution on all that?
sarah: I thought we did, but I’ll go through it again
Matt_King: I may have missed reviewing changes after TPAC, I’ll review again
spectranaut_: there are a lot of comments and only one positive review
… so hoping to get more of those
Matt_King: I’ll review
spectranaut_: we really need someone from Edge and Google to review, right?
sarah: yes, Jocelyn began an implementation
Matt_King: Brett Lewis sent me a video of what he’s done in JAWS, and I thought he demo’d in Chrome
… we have an experimental pattern in APG
sarah: maybe Jocelyn finished a test implementation
spectranaut_: we need to reach out to her
… and maybe also get a positive review on the PR
… sarah, it looks like you’ve resolved jteh’s feedback — so hopefully we can get a positive review from him too
sarah: there was one open question about User Agents MUST — would be nice to get jteh’s response
… there’s still some wordsmithing needed
<Zakim> jcraig, you wanted to taalk about Matt's comments at w3c/
jcraig: this may no longer be an issue, but
… re: the linked comment above from Matt
… the first part was about fingerprinting
… written as an author responsibility and that it opens a wide door
… IMO, this one is not likely to be abused for fingerprinting
… the same event is coming in whether it’s the AT or the mainstream mouse user
… the UI might work differently depending on the author’s implementation
… the second part is where I have more of a concern
… around element requirements
… [ please see comment for context ]
… IMO these are much too rigid and restrictive
… hoping these are no longer an issue
Matt_King: the problem I was reading in the original language
… is that the language of the spec referred to “screen reader focus”
… so we needed a way to get rid of that language
… so that was me spitballing alternatives
… I agree that they’re restrictive
… but I don’t know better alternatives
… we don’t know when screen reader focus is on the element
… we didn’t have anything spec’d that the screen reader can request actions be made visible
… with a SR command
… there’s a chicken and egg problem
… they’re supposed to be focusable so that you *can* click them
jcraig: you don’t know when it’s focused by the AT
… the subtext there is that anytime you want it activateable, it should be visible
… maybe that needs to be explained a bit better
… but a core scenario is Gmail
… a row for an email, with a delete button
… the row itself may or may not be focused
… but the buttons appear when you mouse over
… since you can’t track SR focus
… really those buttons should be debatable at all times
sarah: this seems like a rabbit hole
… the intent was only to reference actual focus
… document.activeElement focus
Matt_King: so then the mention of AT needs to be removed
jcraig: we’re arguing about what visible means
… rendered but transparent
Matt_King: I think the spec isn’t clear the way it’s written
… you should be able to expose the actions available on any element
… but then it’s possible that a SR request would be equivalent to a mouse hover
… there’s an event that the SR can do
… that triggers the availability/visibility of the actions
… the way it is, you’d currently only know the actions if you’re focused on it
sarah: we did talk about this at TPAC
… and one of the proposals was that aria-actions="" (empty string) would be a meaningful mapping
… I have a comment in the PR thread that might address this
… an authors statement
… that clarifies our intention for focus
Matt_King: so is that spec’d now?
sarah: not yet
… I wanted to try this out a little more
… in the course of trying to implement it
… see if it was possible
Matt_King: I think we need some proposed language
jcraig: I think that addresses part of the misunderstanding
… make it visible/available when it’s focused
… but the inverse of that
… is because you don’t necessarily know what AT focuses on something else
… any of these actions could be activatable at any time
… the difference is that if the browser sees that there’s an aria-actions attribute
… but it points to an action that is not available
… then the browser can exclude it
… then when the SR lands on this element, they become available
… it’s saving the privacy, fingerprinting implications
… because of the way the structure works
… but if the actions are always available, then a SR user could access them anytime
Matt_King: that sounds very different than the current spec language
sarah: I did notice something in the core-aam wording that covers this
… have aria-actions added as an object attribute regardless of what’s in it
… so we could add your suggestion for AX mapping, jcraig
… so as far as spec goes, we could add an author MAY/SHOULD add empty string while they’re not rendered, and then populate it when they are
Matt_King: sounds like a user agent MUST then
sarah: please tell me what do for AX API — jcraig, could you help?
<spectranaut_> https://
sarah: yes, please review the rendered preview ☝🏻
sarah: when the element isn’t focused yet and the actions aren’t rendered yet
jcraig: I will chat with some people and see if we need more specific language
… in this mapping, an author could just point to the IDs, and whether they’re exposed could be determined by whether they’re hidden
… if they’re not actionable
… but the DOM attribute doesn’t change
Matt_King: don’t we have to have browser MUST requirements when there‘s a mapping like this?
spectranaut_: if something is in core-aam, then it is a MUST
… but if the browser needs to variably do different things, then it needs to be in the ARIA spec
… if it’s in core-aam it doesn’t also need to be in ARIA
jcraig: it’s somewhere near the top, that everything is normative
… there is an editorial issue claiming that some sections are non-normative
spectranaut_: let’s look into that later
… we have 5 minutes left
… do we have enough time for you, Jane?
Jane: no, let’s wait for the next meeting
Matt_King: I think this answers the question for now, but we need clarity on where/how browser requirements are expressed
… I’ll keep that in mind when I re-review
sarah: to wrap up
… I’m going to go finish the re-wording on the focus thing; remove mention of AT
… and email Joceyln
… update object attribute mapping in aam
… added a comment for jcraig to get input on AX API mapping
… and I think that’s it for me
spectranaut_: and Matt_King will re-review