IRC log of aria on 2024-09-23
Timestamps are in UTC.
- 16:08:04 [RRSAgent]
- RRSAgent has joined #aria
- 16:08:08 [RRSAgent]
- logging to https://www.w3.org/2024/09/23-aria-irc
- 16:08:08 [Zakim]
- RRSAgent, make logs Public
- 16:08:09 [Zakim]
- Meeting: ARIA WG
- 16:09:07 [ZoeBijl]
- scribe: ZoeBijl
- 16:09:19 [ZoeBijl]
- RRSAgent, make minutes
- 16:09:20 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html ZoeBijl
- 16:09:30 [pkra]
- pkra has joined #aria
- 16:09:30 [kschmi]
- kschmi has joined #aria
- 16:09:30 [Jamie]
- Jamie has joined #aria
- 16:09:30 [aardrian]
- aardrian has joined #aria
- 16:09:30 [jamesn]
- jamesn has joined #aria
- 16:09:30 [aaronlev]
- aaronlev has joined #aria
- 16:09:30 [alisonmaher]
- alisonmaher has joined #aria
- 16:09:30 [ethanjv]
- ethanjv has joined #aria
- 16:09:30 [jocelyntran]
- jocelyntran has joined #aria
- 16:09:30 [github-bot]
- github-bot has joined #aria
- 16:09:30 [keithamus]
- keithamus has joined #aria
- 16:09:30 [jcraig]
- jcraig has joined #aria
- 16:09:30 [smockle]
- smockle has joined #aria
- 16:09:58 [ZoeBijl]
- chair: Valerie Young, James Nurthen
- 16:10:07 [ZoeBijl]
- present+
- 16:10:43 [Yusuke]
- Yusuke has joined #aria
- 16:10:43 [pkra]
- pkra has joined #aria
- 16:10:43 [kschmi]
- kschmi has joined #aria
- 16:10:43 [Jamie]
- Jamie has joined #aria
- 16:10:43 [aardrian]
- aardrian has joined #aria
- 16:10:43 [jamesn]
- jamesn has joined #aria
- 16:10:43 [aaronlev]
- aaronlev has joined #aria
- 16:10:43 [alisonmaher]
- alisonmaher has joined #aria
- 16:10:43 [ethanjv]
- ethanjv has joined #aria
- 16:10:43 [jocelyntran]
- jocelyntran has joined #aria
- 16:10:43 [github-bot]
- github-bot has joined #aria
- 16:10:43 [keithamus]
- keithamus has joined #aria
- 16:10:43 [jcraig]
- jcraig has joined #aria
- 16:10:43 [smockle]
- smockle has joined #aria
- 16:11:07 [Daniel]
- present+
- 16:11:59 [ZoeBijl]
- [everyone doing introductions]
- 16:14:27 [Yusuke]
- present+
- 16:14:49 [Jamie]
- present+
- 16:15:22 [alice]
- present+
- 16:16:03 [sarah]
- sarah has joined #aria
- 16:16:52 [jamesn]
- Meeting: ARIA WG - TPAC - Day 1
- 16:17:01 [sarah]
- present+
- 16:17:03 [keithamus]
- present+
- 16:17:04 [ZoeBijl]
- VY: let’s go over the process review
- 16:17:07 [jcraig]
- present+
- 16:17:16 [ZoeBijl]
- first topic: monorepo
- 16:17:22 [ZoeBijl]
- topic: review: monorepo
- 16:17:31 [ZoeBijl]
- one repo for all the specs
- 16:17:41 [ZoeBijl]
- all other repos still exist for issues
- 16:17:53 [ZoeBijl]
- makes making PRs easier
- 16:18:54 [aaronlev]
- aaronlev has joined #aria
- 16:18:57 [ZoeBijl]
- if you have related issues you can open an issue against the monorepo
- 16:19:04 [ZoeBijl]
- the goal is to have things less spread out
- 16:19:14 [ZoeBijl]
- topic: review: normative pr checklist
- 16:19:39 [ZoeBijl]
- we refined the checklist after monorepo
- 16:19:53 [ZoeBijl]
- https://github.com/w3c/aria/pull/2245
- 16:20:14 [ZoeBijl]
- Github: https://github.com/w3c/aria/pull/2245
- 16:20:32 [ZoeBijl]
- topic: getting closer to “can i use” for aria features
- 16:21:05 [ZoeBijl]
- VY: new test for accname
- 16:21:09 [ZoeBijl]
- topic: feedback
- 16:21:26 [ZoeBijl]
- VY: overall process for landing PRs is long
- 16:21:37 [ZoeBijl]
- we’ve made changes over the last couple of years before landing
- 16:21:45 [ZoeBijl]
- based on my experience on my experience
- 16:21:59 [ZoeBijl]
- it’s nice to know that you’re reading something that’s already being implemented
- 16:22:10 [ZoeBijl]
- probably we should review the PR backlog a bit more
- 16:22:12 [jamesn]
- q?
- 16:22:16 [ZoeBijl]
- any suggestions on that are welcome
- 16:22:41 [ZoeBijl]
- specifically normative changes, adding a new feature, etc, maybe we should consider having a champion
- 16:22:59 [ZoeBijl]
- having it more explicit would be nice
- 16:23:51 [keithamus]
- q+
- 16:24:02 [jamesn]
- ack keithamus
- 16:24:11 [ZoeBijl]
- KA: the TC39 staging process is quite ?? ??
- 16:24:13 [scott]
- scott has joined #aria
- 16:24:16 [ZoeBijl]
- it gives a series of gates
- 16:24:23 [ZoeBijl]
- quality control
- 16:24:29 [pkra]
- pkra has joined #aria
- 16:24:32 [ZoeBijl]
- it might be quite a heavy process for ARIA WG
- 16:24:42 [ZoeBijl]
- VY: also Mel brouhght this up
- 16:24:43 [jcraig]
- s/?? ??/robust/
- 16:24:49 [keithamus]
- s/?? ??/thoroughly excercised process
- 16:25:09 [jcraig]
- s/robust/thoroughly excercised/
- 16:25:12 [Matt_King]
- Matt_King has joined #aria
- 16:25:20 [ZoeBijl]
- KA: stage one is worthwhile exploring
- 16:25:33 [ZoeBijl]
- KA: stage two: ??
- 16:25:37 [ZoeBijl]
- KA: stage three: ??
- 16:25:44 [ZoeBijl]
- KA: stage four: ??
- 16:25:56 [ZoeBijl]
- it’s good for exploring ideas
- 16:26:01 [ZoeBijl]
- not sure if suitable for ARIA
- 16:26:02 [jcraig]
- s/four: ??/four: effectively landed/
- 16:26:11 [spectranaut_]
- q?
- 16:26:11 [Matt_King]
- q?
- 16:26:14 [ZoeBijl]
- additional guidelines that say that each proposal needs a champion
- 16:26:22 [Matt_King]
- q+
- 16:26:24 [ZoeBijl]
- we can take parts of that process or none of it
- 16:26:24 [masonf]
- masonf has joined #aria
- 16:26:28 [ZoeBijl]
- there’s precedent there
- 16:26:36 [ZoeBijl]
- and if we’re interested in picking that up
- 16:26:56 [ZoeBijl]
- VY: we’re not very good at marking when things ahve concensus
- 16:26:56 [jcraig]
- s/KA:/keithamus:/g
- 16:27:06 [ZoeBijl]
- we mark it as “waiting for implementation”
- 16:27:17 [kzms2]
- kzms2 has joined #aria
- 16:27:22 [ZoeBijl]
- but maybe we should tag it as “consensus”
- 16:27:28 [ZoeBijl]
- s/concensus/consensus/
- 16:27:33 [Matt_King]
- q-
- 16:27:46 [ZoeBijl]
- keithamus: there are provisions for implementers
- 16:28:00 [ZoeBijl]
- so when it hits stage three, they can move to implementation
- 16:28:07 [ZoeBijl]
- this is to prevent them from implementing too early
- 16:28:09 [jcraig]
- q+
- 16:28:18 [ZoeBijl]
- gives room for prototyping and polyfilling
- 16:28:26 [ZoeBijl]
- jcraig:
- 16:28:37 [ZoeBijl]
- jcraig: which of those stages includes a call for IT review?
- 16:28:50 [Matt_King]
- q+ about evergreen
- 16:28:57 [ZoeBijl]
- which of those would be the most appropriate to include the legal powers that be
- 16:28:57 [Jamie]
- s/IT/IP/
- 16:29:12 [ZoeBijl]
- keithamus: every year in may there’s an opt out period
- 16:29:18 [ZoeBijl]
- usually that’s met with silence
- 16:29:18 [jamesn]
- q++
- 16:29:24 [spectranaut_]
- ack jcraig
- 16:29:25 [flackr]
- flackr has joined #aria
- 16:29:28 [jamesn]
- q-+
- 16:29:29 [aaronlev]
- q+
- 16:29:33 [ZoeBijl]
- aroudn that time things get merged into the mainline
- 16:29:38 [jcraig]
- s/IT review/IP review/
- 16:29:40 [ZoeBijl]
- s/aroudn/around/
- 16:29:50 [spectranaut_]
- ack about
- 16:29:52 [flackr]
- present+
- 16:30:00 [spectranaut_]
- ack evergreen
- 16:30:08 [keithamus]
- s/stage two: ??/stage two: a draft specification is available for review
- 16:30:25 [ZoeBijl]
- MK: ?? the process that keith was describing
- 16:30:27 [ChrisCuellar]
- ChrisCuellar has joined #aria
- 16:30:33 [keithamus]
- s/stage three: ??/stage three: is a signal for implementers to start developing the feature
- 16:30:40 [ZoeBijl]
- JN: every two years you take a CR? through the process
- 16:30:57 [ZoeBijl]
- MK: with evergreen my question is
- 16:31:00 [keithamus]
- s/stage four: ??/stage four: specifications have been reviewed and it is ready to merge into the main specification
- 16:31:01 [ZoeBijl]
- when is something in the spec
- 16:31:15 [ZoeBijl]
- when would we say something is in the spec?
- 16:31:22 [yusuke]
- yusuke has joined #aria
- 16:31:24 [ZoeBijl]
- JN: when you merge the pr
- 16:31:32 [ZoeBijl]
- that’s when it’s essentially in the spec
- 16:31:42 [ZoeBijl]
- MK: don’t we first merge into main?
- 16:31:49 [ZoeBijl]
- and then cut into CR?
- 16:31:59 [ZoeBijl]
- ??: as soon as you merge to main it publishes
- 16:32:11 [keithamus]
- s/??: as/DM: as/
- 16:32:12 [ZoeBijl]
- MK: so essentially the editors draft is published to TR
- 16:32:23 [jcraig]
- s/DM: /Daniel: /
- 16:32:27 [ZoeBijl]
- so merging is the decision point?
- 16:32:49 [ZoeBijl]
- Daniel: starting by 2025 we’ll be able to do that
- 16:32:55 [spectranaut_]
- q?
- 16:32:59 [ZoeBijl]
- spectranaut_: by 2025 we’ll evergreen all specs
- 16:33:03 [spectranaut_]
- ack aaronlev
- 16:33:09 [jcraig]
- rrsagent, make minutes
- 16:33:10 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html jcraig
- 16:33:17 [ZoeBijl]
- aaronlev: just talking about the process
- 16:33:17 [ZoeBijl]
- having exact stages
- 16:33:17 [ZoeBijl]
- that would be useful
- 16:33:29 [ZoeBijl]
- but ?? that there aren’t many people that have time
- 16:33:32 [ZoeBijl]
- because busy with jobs etc
- 16:33:34 [jcraig]
- s/effectively landed/specifications have been reviewed and it is ready to merge into the main specification/
- 16:33:42 [ZoeBijl]
- so there might be a high burden on people like Scott
- 16:33:48 [keithamus]
- q+
- 16:33:58 [ZoeBijl]
- i wouldn’t want to commit to it unless i see that it wouldn’t slow is down to a crawl
- 16:34:05 [ZoeBijl]
- so evergreen is for all specs including aam?
- 16:34:09 [jamesn]
- ack keithamus
- 16:34:09 [spectranaut_]
- ack keithamus
- 16:34:17 [jcraig]
- rrsagent, make minutes
- 16:34:18 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html jcraig
- 16:34:25 [ZoeBijl]
- keithamus: so the tc39 process is an attempt to devolve the editorial burden
- 16:34:25 [aaronlev]
- q-
- 16:34:29 [ZoeBijl]
- the idea of having champion burden the process through
- 16:34:38 [ZoeBijl]
- so editors don’t have to do all the heavy lifting
- 16:34:45 [ZoeBijl]
- i think that would be the benefit of having champions
- 16:34:56 [ZoeBijl]
- aaronlev: is that something we could try ona few issues?
- 16:35:09 [hdv]
- hdv has joined #aria
- 16:35:11 [ZoeBijl]
- keithamus: i think there are a small handful of proposals
- 16:35:14 [hdv]
- present+
- 16:35:17 [ZoeBijl]
- we’re looking how well it fits
- 16:35:26 [ZoeBijl]
- it’s more for nacent? proposals
- 16:35:34 [ZoeBijl]
- spectranaut_: as far as i would think about thinking about this
- 16:35:41 [ZoeBijl]
- just having a bit more clarity
- 16:35:41 [smockle]
- s/nacent?/nascent
- 16:35:52 [ZoeBijl]
- when spec changes have consencus of the working group
- 16:36:08 [Jamie]
- q+
- 16:36:10 [ZoeBijl]
- implementation should inform the specification
- 16:36:19 [ZoeBijl]
- i wonder if the staging process can help us
- 16:36:26 [ZoeBijl]
- get clarity of where a feature is in the process
- 16:36:39 [ZoeBijl]
- MK: i love that idea
- 16:36:40 [spectranaut_]
- q?
- 16:36:42 [ZoeBijl]
- just having a PR
- 16:37:01 [ZoeBijl]
- and being able to say this is in this stage and being liket his is what that means
- 16:37:11 [ZoeBijl]
- JT: if stage three is ready for implementation
- 16:37:16 [ZoeBijl]
- if something goes belly up in stage three
- 16:37:25 [ZoeBijl]
- and during implementation there’s a major problem
- 16:37:29 [ZoeBijl]
- how does that go back to the spec?
- 16:37:32 [ZoeBijl]
- like we need to review
- 16:37:42 [ZoeBijl]
- keithamus: it’s possible to demote issues to prior stages
- 16:37:55 [ZoeBijl]
- we’ve had this with a few issues
- 16:38:20 [ZoeBijl]
- with 2.7, we have most of, what you would call a final draft, seeking at least one implementer to implement it
- 16:38:46 [keithamus]
- https://tc39.es/process-document/
- 16:38:47 [ZoeBijl]
- JT: ah so stage three is for all implementers to implement and stage two has one implementer?
- 16:38:49 [ZoeBijl]
- keithamus: yea
- 16:39:05 [ZoeBijl]
- i linked the process in the IRC so everyone can read it
- 16:39:12 [ZoeBijl]
- VY: six minutes left
- 16:39:19 [jocelyntran]
- jocelyntran has joined #aria
- 16:39:21 [ZoeBijl]
- s/VY/spectranaut_/
- 16:39:34 [ZoeBijl]
- any questions about process?
- 16:39:34 [ChrisCuellar_]
- ChrisCuellar_ has joined #aria
- 16:39:34 [smockle]
- q+
- 16:39:34 [ZoeBijl]
- or this particular idea?
- 16:39:44 [spectranaut_]
- ack Jamie
- 16:39:50 [spectranaut_]
- ack smockle
- 16:39:55 [ZoeBijl]
- smockle: do we have a sense of where our in -flight things are in this process?
- 16:40:04 [ZoeBijl]
- spectranaut_: next we’re talking about popover
- 16:40:09 [ZoeBijl]
- which is an HTML feature
- 16:40:14 [ZoeBijl]
- has mappings in aam
- 16:40:20 [ZoeBijl]
- it’s not an aria feature
- 16:40:23 [ZoeBijl]
- aria-actions
- 16:40:27 [ZoeBijl]
- what stage is that in?
- 16:40:37 [ZoeBijl]
- SH: waiting for implementation
- 16:40:46 [ZoeBijl]
- JN: do we have an implementation behind a featiure flag?
- 16:40:49 [ZoeBijl]
- SH: not yet
- 16:40:58 [aaronlev]
- For the next talk on popovers, and for other talks today and tomorrow...
- 16:40:58 [aaronlev]
- New web platform feature improvements in HTML and CSS (things that have a significant a11y story):
- 16:40:58 [aaronlev]
- https://docs.google.com/document/d/1lg5jC1vLSRBBLPHq-F0MnmQZfkuTUwaOKt7C2WImPCM/edit#heading=h.d7widsnuldsf
- 16:41:02 [ZoeBijl]
- spectranaut_: let’s do this during the rest of TPAC
- 16:41:09 [ZoeBijl]
- state which stage things are in
- 16:41:23 [ZoeBijl]
- MK: is there anything in the process that prevents people from implementing?
- 16:41:33 [ZoeBijl]
- keithamus: there’s not anything particularly stopping you
- 16:41:50 [ZoeBijl]
- but the issue won’t process before the group has consensus
- 16:42:05 [ZoeBijl]
- MK: if we did go to a process like this?
- 16:42:12 [ZoeBijl]
- would we go to some sort of ??? process?
- 16:42:42 [ZoeBijl]
- spectranaut_: might add more buearocracy
- 16:42:49 [Jamie]
- s/???/CFC/
- 16:43:05 [ZoeBijl]
- s/buearocracy/bureaucracy/
- 16:43:18 [ZoeBijl]
- spectranaut_: would be good to have similar stages
- 16:43:32 [ZoeBijl]
- MK: could be that the process is different for different issues
- 16:43:40 [ZoeBijl]
- new feature should follow this
- 16:43:45 [ZoeBijl]
- but editor changes probably don’t
- 16:45:52 [ZoeBijl]
- [more introductions happening since new people joined]
- 16:46:24 [aaronlev]
- aaronlev has joined #aria
- 16:46:56 [alisonmaher]
- alisonmaher has joined #aria
- 16:47:04 [jcraig]
- scribe+ jcraig
- 16:47:09 [ZoeBijl]
- topic: popover
- 16:47:09 [jcraig]
- Topic: popover
- 16:47:39 [aaronlev]
- hi
- 16:47:50 [TylerWilcock]
- TylerWilcock has joined #aria
- 16:47:50 [jcraig]
- AL: quite a few new HTML features being added
- 16:48:03 [jamesn]
- https://docs.google.com/document/d/1lg5jC1vLSRBBLPHq-F0MnmQZfkuTUwaOKt7C2WImPCM/edit#heading=h.83kbi4fzoerk
- 16:48:47 [jcraig]
- dialog element for example does everything for you... so authors can't make as many mistakes
- 16:49:01 [jcraig]
- aaronlev: thanks jocelyntran for compiling this document
- 16:49:23 [jcraig]
- a/AL:/aaronlev:/g
- 16:49:48 [jcraig]
- aaronlev: run this in a nightly build of chrome
- 16:50:18 [jcraig]
- aaronlev: masonf has been working hard on the implementation of popover
- 16:50:36 [jcraig]
- diff b/w auto/manual hint type
- 16:50:47 [aaronlev]
- <button popovertarget="mypopover">Toggle the popover</button>
- 16:50:47 [aaronlev]
- <div id="mypopover" role="..." popover>Popover content</div
- 16:51:17 [benbeaudry]
- benbeaudry has joined #aria
- 16:51:28 [jcraig]
- popover drawn in top layer, above max z-index
- 16:51:50 [benbeaudry]
- present+
- 16:52:01 [ZoeBijl]
- RRSAgent, make minutes
- 16:52:03 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html ZoeBijl
- 16:52:17 [jcraig]
- if you open an auto popover and there's an existing one (non nested) it will close any non-ancestor popover
- 16:52:36 [jcraig]
- masonf: you can have a stack of nested popovers too
- 16:53:00 [jcraig]
- web app can also manage any numbe rof manual popovers
- 16:53:32 [jcraig]
- popover handles some kb nav, like focus cycle containment and escape key to close
- 16:53:43 [scott]
- present+
- 16:54:06 [jcraig]
- mk: if it's not next in the DOM, how does tabbing work?
- 16:54:26 [scott]
- q+
- 16:54:33 [jcraig]
- aaronlev: think of the popover tab cycle like a separate tree or branch in the tab cycle
- 16:54:57 [spectranaut_]
- q?
- 16:55:24 [aaronlev]
- aaronlev has joined #aria
- 16:55:24 [jcraig]
- masonf: one example ov manual popovers is that you can have one popover associated with an individual triggering element
- 16:55:30 [keithamus]
- q+
- 16:55:35 [spectranaut_]
- ack scott
- 16:56:15 [cyns]
- cyns has joined #aria
- 16:56:27 [jcraig]
- scott: can't always put the popover "next to" the triggering element... popover in a paragraph example. most times you want it associated with a trigger button, but sometimes you can't.
- 16:56:38 [jamesn]
- q+
- 16:57:07 [Jamie]
- s/can't/can't; e.g. if the trigger is in the middle of a paragraph/
- 16:57:35 [jcraig]
- aaronlev: popover type and target are separate from the concept of the user action that triggered it.. click/hover
- 16:58:03 [jcraig]
- working out how touch etc will work
- 16:58:14 [jcraig]
- masonf: discussing this in CSS WG tomorrow too
- 16:58:17 [jamesn]
- q-
- 16:58:43 [Francis_Storr]
- Francis_Storr has joined #aria
- 16:59:21 [spectranaut_]
- ack keithamus
- 16:59:29 [jcraig]
- aaronlev: popover implemented well in all major browsers, needs more work in SRs
- 16:59:43 [jcraig]
- autofocus attr also affect popover
- 16:59:49 [aardrian]
- Q+
- 17:00:16 [jcraig]
- s/autofocus attr also affect popover/keithamus: autofocus attr also affect popover/
- 17:00:38 [spectranaut_]
- jcraig: areas of interest, there is ongoing support that we add when we can, tyler have you worked on popover, but we are working on it
- 17:00:50 [ZoeBijl]
- scribe: spectranaut_
- 17:00:50 [spectranaut_]
- q?
- 17:01:32 [jcraig]
- aaronlev: open issues like out-of-band popovers... e.g. trigger from server timeout
- 17:02:03 [jcraig]
- or user getting lost... modal versus non-modal issues.
- 17:02:12 [spectranaut_]
- ack aardrian
- 17:02:47 [Matt_King]
- q?
- 17:02:59 [Matt_King]
- q+
- 17:03:31 [jcraig]
- [discussion of some Windows AT mappings]
- 17:04:45 [aardrian]
- JAWS used to offer a command to navigate to targets with aria-controls, is there a similar concept on deck here?
- 17:05:35 [spectranaut_]
- ack Matt_King
- 17:05:43 [jcraig]
- aaronlev: seeking more people to contribute to the open issues
- 17:05:46 [ZoeBijl]
- s/MK/Matt_King/g
- 17:06:33 [scott]
- q+
- 17:06:44 [jcraig]
- Matt_King: re: minimum roles ... seems like this may not be enough to signal to SRs to do something specific... concerned users will have to guess how new HTML features are supposed to work
- 17:07:50 [jcraig]
- aaronlev: "group" is not enough of a minimum role for popover, but we didn't have anything better atm
- 17:08:21 [jcraig]
- Matt_King: authors ideally shuold be able to use this without any thought into the popover implementation...
- 17:08:23 [cyns]
- q+
- 17:08:31 [cyns]
- q-
- 17:08:33 [jcraig]
- aaronlev: interesting prob, but I don't know the solution.
- 17:08:57 [jcraig]
- aaronlev: can't reasonably expect a random author to know about aria-details...
- 17:09:14 [jcraig]
- Q+
- 17:09:23 [cyns]
- q+
- 17:09:29 [scott]
- scott has joined #aria
- 17:09:31 [Jamie]
- q+
- 17:09:34 [jcraig]
- Matt_King: we do expect authors to know that
- 17:09:36 [jamesn]
- ack scott
- 17:10:26 [jcraig]
- scott: went over this in some of the deep dives. provide support for the different patterns of popover that show up on the internet.
- 17:10:52 [jcraig]
- that's why minimum role is more than generic, but not more specific than group
- 17:11:27 [jcraig]
- so many types in the wild that there isnt anything more specific. author can provide a more specific role.
- 17:11:40 [Jamie]
- q-
- 17:12:06 [aaronlev]
- aaronlev has joined #aria
- 17:12:09 [jcraig]
- Matt_King: authors could use the APG examples to get something better.
- 17:12:47 [jcraig]
- scott: yes and more @@@ scott pls fill in
- 17:12:48 [jamesn]
- ack jcraig
- 17:13:25 [ZoeBijl]
- jcraig: it sound slike aaronlev was saying you can’t expect all authors to know about aria-details etc
- 17:13:30 [spectranaut_]
- q+
- 17:13:42 [ZoeBijl]
- you [Matt_king] said something along the lines we do expect people to know that
- 17:13:52 [Jem]
- +1 to James Craig
- 17:14:00 [ZoeBijl]
- we should prioritise users over developers over ?? (rest of the w3c mantra)
- 17:14:33 [ZoeBijl]
- everything written by anyone on the internet, from big websites to someone writing a local blog, have a responsibility to the user
- 17:14:45 [flackr]
- +1
- 17:14:53 [ZoeBijl]
- it’s the implementors job to make the best user experience regardless of what the author did
- 17:15:01 [jamesn]
- ack cyns
- 17:15:24 [aaronlev]
- q?
- 17:15:26 [scott]
- one way to showcase the power of popover is to provide a companion example to some APG demos - to show how an author doesn't need to declare an aria-expanded attribute, or have to write complicated focus management scripting, because autofocus and the popover's automatic tab focus behavior, and even aria-details relationships can be made
- 17:15:26 [scott]
- 'automatically'
- 17:15:28 [aaronlev]
- q+
- 17:15:29 [jcraig]
- cyns: accidental accessibility is important... users expect the web to work no matter what the author did.
- 17:15:36 [jamesn]
- ack spectranaut_
- 17:15:47 [jocelyntran]
- jocelyntran has joined #aria
- 17:15:58 [jcraig]
- spectranaut_: slightly different topic... there are mappings for this feature
- 17:15:59 [Jamie]
- s/over developers over ??/over authors over user agent implementors/
- 17:16:37 [jcraig]
- diffs between that document https://docs.google.com/document/d/1lg5jC1vLSRBBLPHq-F0MnmQZfkuTUwaOKt7C2WImPCM/edit#heading=h.83kbi4fzoerk and what's in html-aam today
- 17:16:54 [jamesn]
- q?
- 17:16:55 [jcraig]
- aaronlev: need to sync that... doc is probably more recent
- 17:17:13 [jamesn]
- ack aaronlev
- 17:17:14 [aaronlev]
- q-
- 17:17:26 [jcraig]
- aaronlev: I don't mind if HTML-AAM lists TBDs
- 17:18:01 [keithamus]
- q+
- 17:18:34 [Matt_King]
- q+
- 17:18:43 [jcraig]
- aaronlev: responding to Matt_King. yes these are more primitives that final controls, but it still makes the authoring experience easier, and the user experience better. ... less dots for the authors to connect.
- 17:18:50 [jamesn]
- ack keithamus
- 17:19:08 [aaronlev]
- q+
- 17:19:09 [jcraig]
- keithamus: speaks to extensible web manifesto.. this is a building block
- 17:19:42 [jcraig]
- intent to deliver higher level functionality (menu list for example) using the same underlying popover mechanic
- 17:19:52 [jamesn]
- ack Matt_King
- 17:20:06 [jcraig]
- popover could be the primitive mechanic beneath many higher level controls
- 17:20:44 [jcraig]
- Matt_King: to the extent we can. avoid breaking well establishing patterns (ex. tabbing out of a non-modal dialog)
- 17:20:55 [keithamus]
- q+
- 17:21:08 [Jamie]
- q+
- 17:21:08 [jamesn]
- ack aaronlev
- 17:21:08 [jcraig]
- we should avoid behaviors that are inconsistent with those user expectations
- 17:21:16 [Jem]
- https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
- 17:21:17 [smockle]
- q+
- 17:21:29 [jamesn]
- ack keithamus
- 17:22:17 [jcraig]
- keithamus: are you saying dialog focus trapping that lets you get to the browser navigation bar is a problem?
- 17:22:22 [jcraig]
- Matt_King: yes
- 17:22:38 [jcraig]
- aaronlev and scott: this has been controversial.
- 17:22:48 [jamesn]
- q?
- 17:23:01 [jcraig]
- alice: I think rather than non-modal dialogs, Matt was talking about dialogs allowing breaking out into the browser UI
- 17:23:13 [jcraig]
- jcraig: thanks alice for the note correction...
- 17:23:35 [jamesn]
- cd Jamie /me going to be open format - as we have at folks in the room how can we improve our coordination
- 17:23:44 [jamesn]
- ack Jamie
- 17:24:06 [jamesn]
- s/
- 17:24:06 [jamesn]
- cd Jamie /me going to be open format - as we have at folks in the room how can we improve our coordination//
- 17:24:32 [jamesn]
- s/
- 17:24:32 [jamesn]
- cd Jamie \/me going to be open format - as we have at folks in the room how can we improve our coordination//
- 17:24:35 [sabidussi_marco]
- sabidussi_marco has joined #aria
- 17:24:37 [jamesn]
- q?
- 17:24:41 [jamesn]
- cd smockle
- 17:24:45 [jamesn]
- ack smockle
- 17:24:46 [jcraig]
- Jamie: if we have complete native features like dialog, the hope is that authors will choose that over some custom/partial/primitive... cautiously optimistic
- 17:25:29 [jcraig]
- clay: bullet inthe doc: "add details relation" will that be annoying for SR users?
- 17:25:33 [jamesn]
- rrsagent, make minutes
- 17:25:34 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html jamesn
- 17:25:40 [sarah]
- q+
- 17:25:47 [jcraig]
- aaronlev: better to give too much info than not enough
- 17:25:50 [Jamie]
- q+
- 17:26:12 [StefanS]
- StefanS has joined #aria
- 17:26:12 [jcraig]
- SR opportunity for UX innovation
- 17:26:24 [hdv]
- q+
- 17:26:43 [jcraig]
- "APG with popover example" was a great idea. who wants to sign up
- 17:26:49 [cyns]
- +1
- 17:26:58 [hdv]
- q-
- 17:27:08 [jcraig]
- hidde, keithamus signed up to create examples
- 17:27:39 [jamesn]
- s/scribe: spectranaut_/scribe+ spectranaut_/
- 17:27:43 [jcraig]
- sarah: rich hovercard examples.... @@@
- 17:27:50 [jamesn]
- rrsagent, make minutes
- 17:27:51 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html jamesn
- 17:28:15 [ZoeBijl]
- s/@@@/you don’t necessarily want to expose those if you’re not a sighted mouse user because they’re just annoying
- 17:28:20 [ZoeBijl]
- s/@@@/you don’t necessarily want to expose those if you’re not a sighted mouse user because they’re just annoying/
- 17:28:21 [jcraig]
- is there a convenient way for an author to say "yes I meant this to be a hint, event though there is no hint in it"
- 17:28:24 [sarah]
- ack me
- 17:28:41 [jamesn]
- ack Jamie
- 17:28:48 [cyns]
- I smell some test cases
- 17:28:54 [jcraig]
- aaronlev: please add those issues to the doc or repo?
- 17:29:29 [jcraig]
- Jamie: need to think about real-world use cases, rather than focusing on theoretical ones.
- 17:29:56 [jcraig]
- spectranaut_: break time
- 17:33:30 [aaronlev]
- aaronlev has joined #aria
- 18:00:47 [sabidussi_marco]
- sabidussi_marco has joined #aria
- 18:04:45 [Adam_Page]
- Adam_Page has joined #aria
- 18:05:12 [alisonmaher]
- alisonmaher has joined #aria
- 18:07:17 [Brett-Lewis]
- Brett-Lewis has joined #aria
- 18:07:33 [jocelyntran]
- jocelyntran has joined #aria
- 18:07:50 [ZoeBijl]
- topic: Process for ARIA working with AT, how can we do better?
- 18:08:01 [ChrisCuellar]
- ChrisCuellar has joined #aria
- 18:08:27 [Jamie]
- Jamie has joined #aria
- 18:09:05 [kschmi]
- kschmi has joined #aria
- 18:09:30 [ZoeBijl]
- jamesn: we’re talking with AT vendors
- 18:09:33 [ZoeBijl]
- we have multiple in the room
- 18:09:45 [ZoeBijl]
- we want to try and improve the process of working with the APG
- 18:09:58 [ethanjv]
- ethanjv has joined #aria
- 18:10:02 [ZoeBijl]
- without getting AT buy in to actually implement feartures we work on
- 18:10:09 [ZoeBijl]
- even if the browser supports them
- 18:10:20 [ZoeBijl]
- if they’re not exposed to the user they get lost
- 18:10:24 [ZoeBijl]
- one example is aria-message
- 18:10:42 [ZoeBijl]
- s/aria-message/aria-errormessage/
- 18:10:53 [ZoeBijl]
- we didn’t get AT buy in with that
- 18:11:00 [ZoeBijl]
- B?: we did support it
- 18:11:04 [ZoeBijl]
- but people didn’t use it
- 18:11:32 [ZoeBijl]
- jamesn: question? how did you know nobody was using it?
- 18:11:40 [ZoeBijl]
- B?: we ran with it being announced on pages
- 18:11:48 [ZoeBijl]
- but we didn’t get any feedback
- 18:12:01 [ZoeBijl]
- it’s still in our code
- 18:12:12 [ZoeBijl]
- the other one that we supported early on were flows from and flows-to
- 18:12:29 [ZoeBijl]
- aria-controls was also brought up today
- 18:12:40 [ZoeBijl]
- and there’s always been this tension with how early do we support something?
- 18:12:45 [ZoeBijl]
- and users need to be requiring
- 18:13:00 [ZoeBijl]
- jamesn: should we require AT commitment as part of our process
- 18:13:11 [ZoeBijl]
- spectranaut_: I think we should but we don’t at the moment
- 18:13:23 [ZoeBijl]
- I collaboration with ATs was too adhoc to make that work
- 18:13:33 [ZoeBijl]
- q?
- 18:13:35 [Matt_King]
- q+
- 18:13:36 [masonf]
- masonf has joined #aria
- 18:13:36 [Jamie]
- q+ to discuss clearly documented use cases, why this new thing is better than other options/patterns, AT commitments, AT contacts
- 18:13:53 [ZoeBijl]
- jamesn: some questions we need to think about?
- 18:14:00 [ZoeBijl]
- 1. should we require commitment from ATs?
- 18:14:04 [ZoeBijl]
- 2. ?? should we do that?
- 18:14:13 [ZoeBijl]
- 3. what kind of guidance should we give?
- 18:14:28 [ZoeBijl]
- 4. (secretly 3) should we @@@?
- 18:14:28 [hdv]
- q+
- 18:14:36 [jamesn]
- ack Matt_King
- 18:14:42 [benbeaudry]
- benbeaudry has joined #aria
- 18:14:47 [benbeaudry]
- present+
- 18:14:47 [ZoeBijl]
- Matt_King: i will be giving an oveerview of ARIA-AT tomorrow
- 18:15:06 [ZoeBijl]
- the net of all that is going to be how we’re making attempts at defining some expectations of some kind for AT
- 18:15:08 [ZoeBijl]
- not normative
- 18:15:10 [ZoeBijl]
- but testable
- 18:15:12 [masonf]
- present+
- 18:15:23 [ZoeBijl]
- that i feel are the kind of things that we can work out in the implementation phase
- 18:15:31 [ZoeBijl]
- aligned witht he stage three
- 18:15:46 [ZoeBijl]
- i don’t have strong, semi strong, opinions about normative requirements
- 18:15:46 [jamesn]
- qv?
- 18:15:53 [ZoeBijl]
- but more so ??
- 18:16:09 [ZoeBijl]
- one thing we definitely learned from this project
- 18:16:10 [ZoeBijl]
- is that the there are a lot of details that really matter
- 18:16:16 [jamesn]
- q+
- 18:16:20 [ZoeBijl]
- in terms of whether or not a feature delivers any value
- 18:16:21 [Jem]
- q+ to ask how we are going to talk about "AT should" and what has been changing in comparison to past practices.
- 18:16:38 [ZoeBijl]
- i don’t think those can all be realistically specced like css for example
- 18:16:41 [cyns]
- cyns has joined #aria
- 18:16:42 [ZoeBijl]
- looking more to the aams
- 18:16:47 [cyns]
- q?
- 18:16:54 [jamesn]
- ack Jamie
- 18:16:54 [Zakim]
- Jamie, you wanted to discuss clearly documented use cases, why this new thing is better than other options/patterns, AT commitments, AT contacts
- 18:16:55 [ZoeBijl]
- they can help us reflect what people are using in real life
- 18:16:56 [cyns]
- q+
- 18:17:08 [ZoeBijl]
- Jamie: not an AT anymore, but wearing a semi AT hat
- 18:17:22 [ZoeBijl]
- clearly documented usecases for why we want certain things are really helpful
- 18:17:32 [ZoeBijl]
- makes it so that at can see why we need it
- 18:17:40 [ZoeBijl]
- and also why is it better than something we already have
- 18:17:49 [ZoeBijl]
- that should make it easier for AT vendors to commit and get on board
- 18:17:49 [Matt_King]
- q?
- 18:17:59 [ZoeBijl]
- as to the how
- 18:18:01 [ZoeBijl]
- i’m not sure
- 18:18:10 [ZoeBijl]
- what AT vendors are willing to commit to
- 18:18:22 [ZoeBijl]
- but they’re more involved with WCAG?
- 18:18:22 [Matt_King]
- q+
- 18:18:33 [ZoeBijl]
- i think we could build those relationships with ARIA too
- 18:18:42 [ZoeBijl]
- in terms of normative guidance
- 18:19:03 [ZoeBijl]
- it’s reasonable to say that ?? should provide information about this element
- 18:19:07 [aaronlev]
- Support matrix for aria-errormessage: https://a11ysupport.io/
- 18:19:09 [jamesn]
- ack hdv
- 18:19:11 [ZoeBijl]
- it’s more about intent than how they do it
- 18:19:25 [ZoeBijl]
- hdv: from an author point of view
- 18:19:42 [ZoeBijl]
- people use aria even if they don’t know if it’s supported well
- 18:19:47 [Jamie]
- s/??? should/AT should/
- 18:19:49 [ZoeBijl]
- they might now that it exists in the spec
- 18:19:56 [cyns]
- q-
- 18:20:04 [aardrian]
- aardrian has joined #aria
- 18:20:11 [jamesn]
- ack jamesn
- 18:20:11 [ZoeBijl]
- more information about how ARIA is actually implemented would be helpful
- 18:20:19 [aardrian]
- present+
- 18:20:20 [ZoeBijl]
- jamesn: follow up question based on Matt
- 18:20:28 [nathanlapre]
- nathanlapre has joined #aria
- 18:20:49 [Jamie]
- s/but they’re more involved with WCAG?/There is conversation about browser vendors being more involved with WCAG without necessarily participating in all the meetings. We could set up similar relationships with AT vendors./
- 18:20:59 [ZoeBijl]
- should we require someone proposing a new feature writing AT tests if it changes AT behaviour?
- 18:21:08 [ZoeBijl]
- Matt_King: that’s too big an ask
- 18:21:09 [jamesn]
- qv?
- 18:21:14 [ZoeBijl]
- i think that would be a community driven thing
- 18:21:15 [jamesn]
- ack Jem
- 18:21:15 [Zakim]
- Jem, you wanted to ask how we are going to talk about "AT should" and what has been changing in comparison to past practices.
- 18:21:28 [keithamus]
- present+
- 18:21:30 [ZoeBijl]
- Jemma: when i joined aria a long time ago
- 18:21:33 [jcraig]
- q+ to address objections vs prioritization, and to clarify a comment I heard last night about "slowing down"
- 18:21:41 [ZoeBijl]
- i was told we don’t dictate what AT should do
- 18:21:50 [ZoeBijl]
- and now we’re talking about what AT…
- 18:22:02 [ZoeBijl]
- now we have AT vendors here
- 18:22:34 [cyns]
- q+
- 18:22:39 [aaronlev]
- q+
- 18:22:52 [ZoeBijl]
- wondering if i’m missing something in this discussion
- 18:22:55 [ZoeBijl]
- is about the principles
- 18:23:04 [jcraig]
- qv?
- 18:23:04 [ZoeBijl]
- jamesn: originally we got a lot of feedback from AT
- 18:23:17 [hdv]
- s/from an author point of view/from an author point of view, I think more tight integration between AT vendors and ARIA would be very helpful, as lack of support and consistent support leads to author confusion
- 18:23:18 [ZoeBijl]
- telling us they didn’t want us to tell them how to do something
- 18:23:31 [smockle]
- q+
- 18:23:39 [Jamie]
- q+ to say that things have changed, lessons have been learned
- 18:23:41 [ZoeBijl]
- but we now know that they appreciate us speccing how something needs to be exposed
- 18:23:44 [jamesn]
- ack Matt_King
- 18:23:46 [Jem]
- q-
- 18:23:47 [jcraig]
- q+ to discus the "at least 2 required vendors" req in more detail
- 18:23:59 [ZoeBijl]
- Matt_King: back to where jamie started
- 18:24:06 [jcraig]
- qv?
- 18:24:07 [ZoeBijl]
- it was extremely helpful to have real world examples
- 18:24:12 [ZoeBijl]
- showing user value
- 18:24:20 [ZoeBijl]
- and business value for at values as well
- 18:24:28 [Jamie]
- s/values/vendors/
- 18:24:41 [ZoeBijl]
- on that specific topic the process that aria-at is following right now and that we’re going to pilot with aria-actions
- 18:24:52 [ZoeBijl]
- we have one, thanks to adam, functioning example
- 18:25:05 [ZoeBijl]
- we’ll take a look at the experimental features too
- 18:25:11 [ZoeBijl]
- in the discussion tomorrow
- 18:25:25 [ZoeBijl]
- we’d have multiple
- 18:25:38 [ZoeBijl]
- and then from that the aria cg can work with the at vendors on
- 18:25:44 [ZoeBijl]
- what are some baseline expectations?
- 18:25:48 [ZoeBijl]
- my biggest concern
- 18:26:04 [ZoeBijl]
- is characterising it beyond that is testability
- 18:26:20 [ZoeBijl]
- at least at this point in time it’s better to have something looser than that
- 18:26:28 [ZoeBijl]
- at least until there’s more confidence in the process
- 18:26:45 [ZoeBijl]
- and to hdv’s point, knowing support/interoperability is the goal of aria-at
- 18:26:53 [jamesn]
- ack jcraig
- 18:26:53 [Zakim]
- jcraig, you wanted to address objections vs prioritization, and to clarify a comment I heard last night about "slowing down" and to discus the "at least 2 required vendors" req in
- 18:26:56 [Zakim]
- ... more detail
- 18:26:58 [ZoeBijl]
- s/support/support levels/
- 18:27:08 [ZoeBijl]
- jcraig: jamesn and i were disucssing this in the hallway
- 18:27:15 [ZoeBijl]
- if there’s something coming in the spec
- 18:27:39 [ZoeBijl]
- we, as in general, tried to object to things that are not implementable or are a bad idea for implementations
- 18:27:47 [ZoeBijl]
- but nothing in the spec would fall into that category
- 18:27:54 [ZoeBijl]
- like aria-errormessage
- 18:28:08 [ZoeBijl]
- another thing to clarify is that it’s a matter of prioritisation
- 18:28:17 [Matt_King]
- q+ to ask about aria-hotkeys
- 18:28:24 [ZoeBijl]
- basically everything that’s in the spec all the chain down
- 18:28:37 [ZoeBijl]
- it’s just not made it’s way to that prioritisation
- 18:28:49 [Matt_King]
- yes
- 18:28:54 [ZoeBijl]
- some stuff has a lower priority than existing bugs in implemented features
- 18:29:05 [ZoeBijl]
- when aria first started there wasn’t even a plan for testability
- 18:29:17 [ZoeBijl]
- it was essentially microdata that was jammed in the html
- 18:29:59 [ZoeBijl]
- what’s happened over the years, the spec editors wrote a bunch of stuff that didn’t make it all the way through the chain
- 18:30:10 [ZoeBijl]
- i want to get back around to this idea of testability
- 18:30:23 [ZoeBijl]
- to clarify
- 18:30:39 [ZoeBijl]
- we’re now at a position where we can reasonably test some things in an automated way
- 18:30:50 [ZoeBijl]
- spectranaut_ will talk about that later in the day
- 18:31:09 [ZoeBijl]
- the comment about slowing down is that there’s already a lot of ARIA out there that doesn’t work
- 18:31:26 [ZoeBijl]
- we don’t want to add another layer of ARIA that doesn’t work in a different way
- 18:31:28 [ZoeBijl]
- [laughter]
- 18:31:40 [ZoeBijl]
- plus some of the new html features like aaron discussed this morning
- 18:31:50 [ZoeBijl]
- that’s kind of the focus of this slowing down
- 18:32:01 [ZoeBijl]
- my interpretation is that we should focus on the automated testability
- 18:32:11 [jamesn]
- ack cyns
- 18:32:16 [Jem]
- James Craig's comments help to answer to some of my questions. - improved automated testing procedures, which are different from the past.
- 18:32:40 [ZoeBijl]
- cyns: ??
- 18:32:47 [ZoeBijl]
- we’re at a point now where I think we can start to fill that gap
- 18:32:56 [ZoeBijl]
- and so yes there’s the don’t box people in and stop them from innovating
- 18:33:04 [ZoeBijl]
- but also there needs to be a place to argue
- 18:33:08 [ZoeBijl]
- provide feedback
- 18:33:19 [ZoeBijl]
- like working in a public group makes it easier for everyone
- 18:33:30 [ZoeBijl]
- i think some of the at people agree
- 18:33:31 [jamesn]
- ack aaronlev
- 18:33:33 [jcraig]
- s/ in an automated way/ in an automated way in existing and emerging WPT/
- 18:33:39 [ZoeBijl]
- aaronlev: as others have mentioned
- 18:33:48 [ZoeBijl]
- i don’t think at people don’t want any input
- 18:33:55 [ZoeBijl]
- but do appreciate some documentation
- 18:34:12 [ZoeBijl]
- the only thing that gets stuff done and get it done well
- 18:34:13 [jcraig]
- s/spectranaut_ will talk about that later in the day/spectranaut_ will talk about the next step in that (automated platform mappings) later in agenda/
- 18:34:21 [ZoeBijl]
- is when authors start using the new markup
- 18:34:25 [ethanjv]
- ethanjv has joined #aria
- 18:34:45 [ZoeBijl]
- thinking back to css and you get all the bloggers talking about new features
- 18:34:52 [ZoeBijl]
- who’s doing that for aria stuff?
- 18:34:58 [ZoeBijl]
- we need an authoring community
- 18:35:10 [ZoeBijl]
- showing off the new stuff
- 18:35:18 [hdv]
- q+
- 18:35:28 [jamesn]
- ack smockle
- 18:35:32 [ZoeBijl]
- what i need from at vendors is that want to wait until people are using it
- 18:35:50 [ZoeBijl]
- Clay: ?? what kind of setting AT should support?
- 18:35:53 [cyns]
- q+
- 18:35:58 [hdv]
- q+ to respond to aaron re talking about new ARIA features
- 18:36:09 [ZoeBijl]
- can we tell AT vendors what we think would work well? in terms of settings?
- 18:36:16 [ZoeBijl]
- like aria-notify
- 18:36:28 [jcraig]
- q+ to discuss can-i-use? respec vs bikeshed markings
- 18:36:29 [ZoeBijl]
- we would probably want that setting supported in at?
- 18:36:41 [ZoeBijl]
- aaronlev: what i was thinking
- 18:36:45 [ZoeBijl]
- i’m not a sr user
- 18:37:02 [ZoeBijl]
- people that need to have that conversation should be at users and vendors
- 18:37:14 [jamesn]
- ack Jamie
- 18:37:16 [Zakim]
- Jamie, you wanted to say that things have changed, lessons have been learned
- 18:37:17 [ZoeBijl]
- as a browser vendor i don’t want to be too involved
- 18:37:31 [ZoeBijl]
- Jamie: there has been a change in terms of what at vendors want to discuss
- 18:37:41 [jcraig]
- q+ to review this in that context https://github.com/speced/respec/issues/4633
- 18:37:42 [ZoeBijl]
- not having any guidance doesn’t help anyone
- 18:37:54 [jamesn]
- zakim, close the queue
- 18:37:54 [Zakim]
- ok, jamesn, the speaker queue is closed
- 18:37:55 [ZoeBijl]
- i think in the last few years there has been more appetite
- 18:37:59 [hdv]
- q-
- 18:37:59 [jamesn]
- qv?
- 18:38:05 [jamesn]
- ack Matt_King
- 18:38:05 [Zakim]
- Matt_King, you wanted to ask about aria-hotkeys
- 18:39:09 [ZoeBijl]
- Matt_King: way back to where, two things, jcraig, i was under the impression that you had comments on aria-keys?
- 18:39:11 [jcraig]
- qv?
- 18:39:20 [ZoeBijl]
- is there anything that we should just not put into the spec?
- 18:39:34 [jamesn]
- ack cyns
- 18:39:36 [ZoeBijl]
- github: https://github.com/speced/respec/issues/4633
- 18:39:52 [jcraig]
- q+ to respond to matt's comment about aria-keyshortcuts an aria-grabbed
- 18:39:52 [ZoeBijl]
- cyns: we get input from sr users
- 18:40:00 [ZoeBijl]
- and we don’t get as much input from other at users
- 18:40:09 [ZoeBijl]
- i tried to do user research
- 18:40:11 [jcraig]
- qv?
- 18:40:21 [ZoeBijl]
- i’ve been thinking a lot about how we as a wg could fund some user research
- 18:40:27 [ZoeBijl]
- getting real answers about what users want
- 18:40:39 [ZoeBijl]
- i don’t know how that funding would work but how can we make that happen?
- 18:40:47 [ZoeBijl]
- just an idea that i want to put out there?
- 18:40:48 [jamesn]
- ack jcraig
- 18:40:48 [Zakim]
- jcraig, you wanted to discuss can-i-use? respec vs bikeshed markings and to review this in that context https://github.com/speced/respec/issues/4633
- 18:41:05 [ZoeBijl]
- jcraig: responding to matt about features
- 18:41:14 [ZoeBijl]
- i don’t know that i objected to aria-???
- 18:41:19 [ZoeBijl]
- s/???/grabbed/
- 18:41:20 [Jem]
- I think we can have a partnership and collaboration with the disability advocacy group.
- 18:41:31 [ZoeBijl]
- jcraig: aria-keyshortcuts i had concerns about
- 18:41:42 [ZoeBijl]
- like the french keyboard has some intersting keys
- 18:41:51 [ZoeBijl]
- like other keyboards have other limitations
- 18:42:03 [ZoeBijl]
- like gmail has different shortcuts for french users
- 18:42:23 [ZoeBijl]
- so as long as those keyshortcuts are adjusted to locales it should be fine
- 18:42:29 [sabidussi_marco]
- sabidussi_marco has joined #aria
- 18:42:36 [ZoeBijl]
- [something about an objections]
- 18:42:49 [ZoeBijl]
- it’s not that it’s not implemented because of a formal objection
- 18:43:10 [ZoeBijl]
- one of the things someone mentioned was this can i use site
- 18:43:18 [ZoeBijl]
- effectively showing you if you can use a css feature
- 18:43:26 [ZoeBijl]
- it has notes about browser version support etc
- 18:43:36 [ZoeBijl]
- can also have notes about accessibility
- 18:43:44 [jcraig]
- https://github.com/speced/respec/issues/4633
- 18:44:00 [ZoeBijl]
- Github: https://github.com/speced/respec/issues/4633
- 18:44:17 [ZoeBijl]
- one of the ways in which we may consider doing this is an in spec can i use
- 18:44:24 [ZoeBijl]
- some note or graphic that shows the support
- 18:44:38 [ZoeBijl]
- maybe some automated or periodically manual updating
- 18:44:50 [ZoeBijl]
- there’s a lot of AT
- 18:44:55 [ZoeBijl]
- we can’t list all of them
- 18:45:03 [ZoeBijl]
- but we can have the major screen readers for example
- 18:45:12 [ZoeBijl]
- maybe add this to respec?
- 18:45:16 [Jem]
- I wonder how this "can I use aria "will be different from AT project.
- 18:45:58 [ZoeBijl]
- jamesn: we’re at time
- 18:46:01 [Jem]
- so "can I use" is more about 'browser" focused.
- 18:46:02 [ZoeBijl]
- maybe we can get some conclusions
- 18:46:24 [ZoeBijl]
- it feels like everyone is on board with getting formal or informal buy in from AT vendors
- 18:46:47 [ZoeBijl]
- and it seems like everyone is on board with us giving feature guidance, basically how it _could_ be implemented
- 18:46:50 [ZoeBijl]
- not normative
- 18:47:04 [StefanS]
- q+
- 18:47:04 [ZoeBijl]
- Jamie: as long as AT vendors are involved in the process
- 18:47:07 [ZoeBijl]
- jamesn: yes
- 18:47:33 [ZoeBijl]
- for the third one of our requirements, maybe we can pass on that for now until we have more experience? with the stuff leading up to that
- 18:47:49 [ZoeBijl]
- StefanS: how will this buy in be communicated?
- 18:47:56 [ZoeBijl]
- jamesn: through the github issue is my guess?
- 18:48:05 [ZoeBijl]
- spectranaut_: we’ll iterate on that
- 18:48:10 [ZoeBijl]
- Jamie: maybe github labels
- 18:48:28 [ZoeBijl]
- topic: User agent and authoring requirements for aria-actions
- 18:48:37 [hdv]
- scribenick: hdv
- 18:48:47 [Jem]
- https://gist.github.com/mcking65/adb77e66dda4fd024607606528d770c7
- 18:48:53 [hdv]
- Matt_King: in the notes column in the agenda I added this link
- 18:49:01 [jamesn]
- s/scribenick: hdv/scribe+ hdv/
- 18:49:02 [hdv]
- Matt_King: I hope these goals aren't too ambitious
- 18:49:44 [ZoeBijl]
- RRSAgent, make minutes
- 18:49:45 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html ZoeBijl
- 18:49:51 [hdv]
- Matt_King: the goals are across all aria-actons discussions, we have critical decisions to make re requirements
- 18:50:16 [hdv]
- Matt_King: I spent a fair amount of time after some discussions, APG, Sarah, others have worked on this
- 18:50:17 [ZoeBijl]
- s/topic: popover//
- 18:50:21 [ZoeBijl]
- RRSAgent, make minutes
- 18:50:22 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html ZoeBijl
- 18:50:28 [sarah]
- sarah has joined #aria
- 18:51:05 [hdv]
- Matt_King: I don't think we can have a full discussions of some of these questions, so please read the first couple of questions
- 18:51:43 [hdv]
- Topic: aria-actions
- 18:51:48 [Brett-Lewis]
- Brett-Lewis has joined #aria
- 18:52:00 [hdv]
- RRSAgent, make minutes please
- 18:52:01 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html hdv
- 18:52:42 [hdv]
- Matt_King: we need to answer this for all implementations as we don't want differences between the implementations
- 18:53:23 [hdv]
- Jamie: I think the first question has already been answered
- 18:53:33 [hdv]
- Matt_King: great we don't need to set precedent between the two
- 18:53:44 [hdv]
- sarah: the change was made a couple of weeks ago
- 18:53:51 [hdv]
- Jamie: nuance needs to be resolved but will be fine
- 18:54:13 [hdv]
- jamesn: has it been discussed with @@@ ?
- 18:54:17 [hdv]
- s/jamesn/Jamie
- 18:54:27 [hdv]
- sarah: no not yet
- 18:54:33 [hdv]
- jamie: probably won't be a problem
- 18:54:54 [hdv]
- Matt_King: ok let's move to question two
- 18:55:08 [hdv]
- Matt_King: “Must user agents expose aria-actions in the order the IDs are specified by the author?”
- 18:55:17 [sarah]
- q+
- 18:55:19 [hdv]
- Matt_King: I believe we want to make sure authors can control the order of actions
- 18:55:25 [jamesn]
- zakim, open the queue
- 18:55:27 [Zakim]
- ok, jamesn, the speaker queue is open
- 18:55:28 [sarah]
- q+
- 18:55:30 [hdv]
- Matt_King: my proposal is that we add a normative UA req regarding this
- 18:55:42 [jamesn]
- ack sarah
- 18:55:46 [hdv]
- sarah: I agree, I had intended for the order to respect the order of ids
- 18:55:54 [hdv]
- sarah: unless anyone has concerns re the implementation of that
- 18:56:11 [hdv]
- sarah: unless it's better in AAM
- 18:56:12 [hdv]
- Matt_King: I think in other places, where we do it, we have it in ARIA
- 18:56:34 [hdv]
- Jamie: and would be tedious to describe for every AT, as people who read AAM might not read the right section of ARIA
- 18:56:48 [hdv]
- jamesn: we want authors to know as well, they won't read the AAM
- 18:57:21 [hdv]
- Matt_King: let's talk about the third question: “To which descendants must user agents propagate aria-actions?”
- 18:57:49 [hdv]
- Matt_King: in the spec says you could have a container element of some kind, like a dialog, that is referenced in spec def, or a table cell, table row, row group, they could all have actions
- 18:57:56 [jamesn]
- q+ to ask what the use case is for inherited actions
- 18:58:11 [jcraig]
- q+
- 18:58:13 [Jamie]
- q+
- 18:58:24 [hdv]
- Matt_King: where are those actions going to get exposed? it seems to me, since element inside the container can have action and can also inherit action, that the UA has some responsibility for exposing those potentially and propagating them down the tree?
- 18:58:25 [jamesn]
- ack me
- 18:58:25 [Zakim]
- jamesn, you wanted to ask what the use case is for inherited actions
- 18:58:25 [jcraig]
- q+ to respond to "inherited actions"
- 18:58:26 [sarah]
- q+
- 18:58:33 [hdv]
- jamesn: what's the use case for inherited actions?
- 18:58:52 [hdv]
- Matt_King: there is one cited in the definition: closing a dialog from some place inside of the dialog
- 18:59:00 [hdv]
- Matt_King: I don't particularly like that one
- 18:59:16 [jamesn]
- ack jcraig
- 18:59:16 [Zakim]
- jcraig, you wanted to respond to "inherited actions"
- 18:59:17 [hdv]
- jamesn: do we need it or can we make it so that we don't need inherited actions?
- 18:59:37 [hdv]
- jcraig: I can speak to that… one of the examples is closing a dialog
- 19:00:11 [ZoeBijl]
- qv?
- 19:00:14 [hdv]
- jcraig: sometimes users do a different action that closes the dialog or folder, bit like the equivalent of the escape key. You don't necessarily want to think about going back to a higher level before that would work
- 19:01:02 [hdv]
- jcraig: one place where this could be complicated is: how do you reconcile that list? From an authoring perspective, this would be something that could result in a giant list, eg in SAP / Oracle like interface it could be a giant list… say something has the same name, how does the user know which is which?
- 19:01:41 [hdv]
- jcraig: eg in a Gmail table a row has a delete action… maybe you want that delete action on the parent row as well… I think if we have to add something like identifiers it's going to break the simplicity… I don't know the answer
- 19:01:54 [hdv]
- jcraig: one of the way it could work is if there is an action with the same name, we keep the local one
- 19:02:11 [hdv]
- jcraig: so when they both have a delete action we keep the delete action localy and not the inherited one
- 19:02:24 [jamesn]
- ack Jamie
- 19:02:46 [hdv]
- Jamie: first thought I have re this is that it feels like a potential world of pain to me… can see the list growing to 30-40 actions
- 19:03:00 [hdv]
- Jamie: close dialog is an interesting case, but not a match for aria-actions in a lot of times
- 19:03:20 [hdv]
- Jamie: there was discussion in AOM I think re when ATs trigger that action
- 19:03:41 [hdv]
- Jamie: how many use cases are there if we don't count dialog… I worry this may turn into something that people don't use
- 19:03:53 [cyns]
- q+
- 19:03:57 [Matt_King]
- q+
- 19:03:58 [jcraig]
- s/ATs trigger that action/ATs trigger that action, synthesize an Esc key event/
- 19:04:02 [hdv]
- Jamie: one final comment… the spec currently requires something is focusable in order to have actions, which brings the dialog into questions
- 19:04:06 [Matt_King]
- q?
- 19:04:14 [jamesn]
- ack sarah
- 19:04:16 [hdv]
- sarah: yes… maybe we can make that more explicit
- 19:04:34 [hdv]
- sarah: I agree … I don't think actions should be inherited, if there was a use case authors could do that
- 19:04:49 [hdv]
- sarah: I think we wanted to have an example of a container type widget with associated actions
- 19:04:55 [hdv]
- sarah: maybe video player
- 19:05:15 [Adam_Page]
- q+ to give example for aria-actions on container
- 19:05:28 [hdv]
- jamesn: the play/pause button, in theory the play button on my keyboard should trigger the same
- 19:05:54 [hdv]
- s/jamesn/craigj
- 19:05:56 [jamesn]
- ack cyns
- 19:06:03 [hdv]
- craigj: video player is a reasonable example
- 19:06:12 [hdv]
- cyns: much easier to add it later
- 19:06:13 [jamesn]
- ack Matt_King
- 19:06:15 [hdv]
- Jamie: agreed
- 19:06:31 [kschmi]
- kschmi has joined #aria
- 19:06:40 [jcraig]
- s/craigj/jcraig/g
- 19:06:54 [hdv]
- Matt_King: if we're taking away inheritance, what about the video player example? Re the question of focusability
- 19:07:06 [jcraig]
- qv?
- 19:07:08 [hdv]
- Matt_King: most of the things are not focusable, so there is no focusability requirement now
- 19:07:36 [jcraig]
- q+ to discuss focusability
- 19:07:42 [Jamie]
- q+ to clarify "most of the things are not focusable"
- 19:08:23 [jamesn]
- ack Adam_Page
- 19:08:23 [Zakim]
- Adam_Page, you wanted to give example for aria-actions on container
- 19:08:33 [hdv]
- Matt_King: if we take away inheritability we probably need to restrict aria actions to specific elements
- 19:08:56 [sarah]
- q+
- 19:09:15 [jcraig]
- q+ to talk about the click implementation
- 19:09:16 [hdv]
- Adam_Page: another use case for aria actions on a container: a scrolling code block where you can copy the contents of it
- 19:10:04 [hdv]
- Matt_King: how do you do that without inheritance? then you could only access it when focusing the contianer
- 19:10:09 [hdv]
- sarah: yes
- 19:10:17 [hdv]
- Adam_Page: yes that was my intention
- 19:10:53 [StefanS]
- q+
- 19:10:58 [hdv]
- Adam_Page: in this example if makes sense to have the action on the container
- 19:11:35 [hdv]
- Matt_King: when we're talking about inheritance… if you specify aria actions on an element, without inheritance the user of the AT has to be focused on that element in order to activate the action
- 19:11:45 [jamesn]
- ack jcraig
- 19:11:45 [Zakim]
- jcraig, you wanted to discuss focusability and to talk about the click implementation
- 19:11:47 [hdv]
- Matt_King: are we all good on that?
- 19:12:35 [smockle]
- q+
- 19:12:56 [hdv]
- jcraig: I want to make sure everyone understands the reason of this pattern. One of the things that slowed implementation of getting complex web widgets to be accessible is a change that the W3C TAG made in relation to ARIA AT… there is a new design principle, which I agree with in theory, there is no way that a newly designed web feature should leak the details of a user using assistive technology
- 19:13:15 [hdv]
- jcraig: this isn't ARIA specific, CSS and HTML leak this all the time
- 19:13:37 [hdv]
- jcraig: one of the great things of this aria actions proposal is that this way, it can almost entirely mask the use of AT, because it synthesises a click event
- 19:14:40 [smockle]
- q+ to ask about aria-activedescendent
- 19:14:56 [hdv]
- jcraig: eg in Gmail, you are on a row, when you click with mouse on a specific action for that row, it fires on that… what aria-actions inheritance helps with, I want to do things like mark it as spam or move it, authors don't need to set the actions on all the nodes
- 19:15:23 [hdv]
- jcraig: part of the reason there is a requirement for visibility (not focusability), if we try to fire a click event on an element that wasn't rendered, the application may not work
- 19:15:33 [Matt_King]
- q?
- 19:15:37 [jamesn]
- q+
- 19:16:07 [hdv]
- jcraig: because at some point you might get a click event on. Brilliance behind this pattern is that it doesn't leak more details about the AT than it has to… so holds in line with the principle of the TAG
- 19:16:36 [hdv]
- jcraig: the element with the aria actions attribute on it does have to be focusable
- 19:17:00 [jamesn]
- ack Jamie
- 19:17:00 [Zakim]
- Jamie, you wanted to clarify "most of the things are not focusable"
- 19:17:04 [hdv]
- jcraig: so there isn't a req for focusability on the element receiving the action, but there is on the el that is exposing the action
- 19:17:23 [hdv]
- Jamie: re the leave node question: is the concern with that the cell is focusable?
- 19:17:30 [hdv]
- jcraig: first cell have a checkbox in it
- 19:17:41 [hdv]
- Jamie: does that need the actions? not sure how that is a problem?
- 19:17:53 [hdv]
- jcraig: just because I am on the checkbox I don't want to be able to delete or move the message?
- 19:18:02 [hdv]
- Jamie: you've decided to go deeper at that point
- 19:18:17 [hdv]
- Jamie: if you focus the row, which is what you normally do, you get the acttions…
- 19:18:26 [spectranaut_]
- q?
- 19:19:04 [CurtBellew]
- CurtBellew has joined #aria
- 19:19:23 [hdv]
- Jamie: if we allow the AT to walk the ancestor chain, it can say these actions are here and could do something like a submenu
- 19:19:50 [hdv]
- Jamie: allowing for the ancestor thing, the AT has a better idea of what the structure looks like, which you woulnd't have if browser would flatten that
- 19:20:04 [hdv]
- jcraig: agree with that
- 19:20:05 [Matt_King]
- q+ to ask about interop of if AT walk up tree
- 19:20:27 [hdv]
- jcraig: I think implementation would probably work as you described it
- 19:20:40 [hdv]
- Jamie: just wanted to flag that flattening is not the only way
- 19:20:42 [jamesn]
- ack sarah
- 19:20:59 [hdv]
- sarah: I just added the open question, “should screenreaders sometimes expose actions” to my doc
- 19:21:17 [hdv]
- sarah: even in these examples, I don't think we should have inheritance by default, don't think it is hard for an author to duplicate actions
- 19:21:38 [hdv]
- sarah: there are too many contextual things, it depends on the context what level of inheritance is most useful
- 19:22:27 [jamesn]
- q-
- 19:23:00 [hdv]
- sarah: there was a discussion in the PR, that authors should nesure that actions exist in the DOM when the refercing element is focused by the user agent or AT… I wonder if we should make that must and remove the AT bit
- 19:23:13 [jamesn]
- ack StefanS
- 19:23:34 [hdv]
- smockle: I think this discussion would be more helpful if we start with a simple example and then go to more complex one
- 19:24:25 [smockle]
- s/smockle: I think/StefanS: I think
- 19:24:57 [hdv]
- StefanS: more concrete examples should help here
- 19:25:14 [hdv]
- StefanS: and define what the best practice for it would be
- 19:25:15 [jamesn]
- ack smockle
- 19:25:15 [Zakim]
- smockle, you wanted to ask about aria-activedescendent
- 19:25:43 [hdv]
- smockle: could aria-activedescendant containers in trees have actions ?
- 19:25:43 [jamesn]
- ack Matt_King
- 19:25:43 [Zakim]
- Matt_King, you wanted to ask about interop of if AT walk up tree
- 19:26:24 [hdv]
- Matt_King: StefanS, we are going to talk about AT expectations … we do have a simple example in the APG
- 19:26:32 [hdv]
- Matt_King: there are references in the top of the doc to go to the APG
- 19:26:40 [Jem]
- https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-actions/
- 19:26:55 [Jem]
- APG example - Tab actions by Adam Page
- 19:27:16 [hdv]
- Matt_King: re Jamie: when ti comes to what AT can and cannot do… most important is interoperability, would be concerned if one AT does lock up the tree and the other doesn't
- 19:27:24 [hdv]
- Jamie: oh yes I think it should be explicit
- 19:28:03 [hdv]
- Matt_King: if I understood jcraig right, he said the referencing element that has aria-actions on it, must be focusable… if that's correct the allowed roles would have to be changed, because right now it is basically everything
- 19:28:11 [hdv]
- sarah: everything except elements that cannot be named… eg nameable elements
- 19:28:41 [hdv]
- Matt_King: so right now, we don't have people make elements that are in the structural part of the tree focusable just to have aria actions
- 19:28:53 [sarah]
- q+
- 19:28:54 [hdv]
- Matt_King: we don't want to encourage people to make regions focusable so people can have actions on them
- 19:29:10 [jamesn]
- ack sarah
- 19:29:11 [hdv]
- sarah: I think the question is encouraging vs limiting
- 19:29:26 [hdv]
- sarah: eg I wouldn't tell people to make an article focusable
- 19:29:36 [jcraig]
- q+
- 19:29:54 [jamesn]
- zakim, close the queue
- 19:29:54 [Zakim]
- ok, jamesn, the speaker queue is closed
- 19:29:58 [hdv]
- sarah: I think what we came up with last time is that nameable elements can be focused in some cases, eventhough in general you would not want to do that
- 19:30:10 [jcraig]
- q+ to mention that focus is the detectable event to allow the widget to render its actionable elements
- 19:30:12 [hdv]
- Matt_King: right now there isn't anything in prose that says @@@
- 19:30:13 [jcraig]
- ack me
- 19:30:14 [jamesn]
- ack jcraig
- 19:30:14 [sarah]
- ack me
- 20:04:29 [ChrisCuellar]
- ChrisCuellar has joined #aria
- 20:26:19 [Adam_Page]
- Adam_Page has joined #aria
- 20:44:32 [hdv]
- RRSAgent, make minutes please
- 20:44:34 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html hdv
- 20:55:16 [alisonmaher]
- alisonmaher has joined #aria
- 20:56:39 [Adam_Page]
- Adam_Page has joined #aria
- 20:58:26 [jocelyntran]
- jocelyntran has joined #aria
- 20:59:13 [Yusuke]
- Yusuke has joined #aria
- 21:00:21 [sarah]
- sarah has joined #aria
- 21:01:36 [ZoeBijl]
- topic: New CSS Features
- 21:01:51 [smockle]
- present+
- 21:01:52 [smockle]
- scribe+
- 21:02:26 [Matt_King]
- Matt_King has joined #aria
- 21:03:08 [scott]
- scott has joined #aria
- 21:03:27 [Jem]
- https://docs.google.com/document/d/1lg5jC1vLSRBBLPHq-F0MnmQZfkuTUwaOKt7C2WImPCM/edit#heading=h.83kbi4fzoerk
- 21:03:49 [smockle]
- Session: New CSS Features
- 21:04:10 [Brett-Lewis]
- Brett-Lewis has joined #aria
- 21:06:38 [bkardell_]
- bkardell_ has joined #aria
- 21:07:51 [Jamie]
- Jamie has joined #aria
- 21:08:19 [StefanS8]
- StefanS8 has joined #aria
- 21:09:21 [smockle]
- https://www.irccloud.com/pastebin/I0EDjrmz/
- 21:09:51 [StefanS]
- StefanS has joined #aria
- 21:10:26 [smockle]
- Question: Are we discussing ‘where to map’ CSS stuff today?
- 21:10:34 [smockle]
- aaronlev: No, not today.
- 21:10:49 [smockle]
- aaronlev: Right now, it’ll go in html-aam.
- 21:12:08 [smockle]
- aaronlev: We’ll start with CSS Anchor Positioning. Jocelyn is very close to landing this in Chromium.
- 21:12:39 [smockle]
- aaronlev: In the discussion on GitHub, people prefer a 1:1 relationship between the elements.
- 21:13:08 [sabidussi_marco]
- sabidussi_marco has joined #aria
- 21:13:20 [sarah]
- q+
- 21:13:31 [smockle]
- aaronlev: The relationship will be similar to `aria-details`: starting with the anchor, pointing to the thing anchored to it
- 21:13:36 [Matt_King]
- q+
- 21:13:37 [jamesn]
- zakim, open the queue
- 21:13:37 [Zakim]
- ok, jamesn, the speaker queue is open
- 21:13:41 [jamesn]
- q+ Matt
- 21:13:45 [smockle]
- sarah: Are there any role restrictions?
- 21:13:53 [cyns]
- cyns has joined #aria
- 21:14:12 [Jamie]
- Jamie has joined #aria
- 21:14:18 [smockle]
- aaronlev: Should we restrict when we do the automatic aria-details relationship?
- 21:14:46 [smockle]
- aaronlev: `aria-details` can go on anything, so I’m not sure this should have any additional restrictions
- 21:15:03 [smockle]
- aaronlev: Anything with `aria-` causes an element to be exposed in the AT.
- 21:15:11 [smockle]
- s/AT/Accessibility Tree
- 21:15:14 [sarah]
- ack me
- 21:15:18 [jamesn]
- ack Matt_King
- 21:15:22 [jamesn]
- ack M
- 21:15:49 [smockle]
- Matt_King: Do the APIs have a way to tell AT why the relationship exists?
- 21:16:00 [smockle]
- aaronlev: We’re planning details-from for that.
- 21:16:15 [nathan]
- nathan has joined #aria
- 21:16:21 [jamesn]
- q+
- 21:16:38 [Jamie]
- q+
- 21:16:53 [jamesn]
- ack Jamie
- 21:17:07 [smockle]
- Jamie: Real-world use cases is something we need to talk about more.
- 21:17:12 [aardrian]
- aardrian has joined #aria
- 21:17:20 [aardrian]
- present+
- 21:17:53 [smockle]
- Jamie: NVDA, for example, and I think JAWS, if there is a details relationship, it gets exposed. I’m not sure there is a reason to differentiate; the user just needs to know ‘there is more stuff related to this thing’ (and be able to get there).
- 21:18:41 [smockle]
- Matt_King: When I hear about a details relationship, the fact that there *is* a details relationship doesn’t tell me I should care. It would be helpful to expose the meaning.
- 21:19:11 [jcraig]
- q+ to ask if the detailsfrom API Aaron mentioned can be extrapolated in all scenarios from the inverse details relationship, or are you proposing a new content attribute `aria-detailsfrom`
- 21:19:15 [Jamie]
- q-
- 21:19:18 [smockle]
- Jamie: Three are many cases of that, e.g. if a button has a dialog, you don’t know what that dialog is going to be.
- 21:19:23 [jamesn]
- ack jamesn
- 21:19:47 [jcraig]
- ack me
- 21:19:48 [jamesn]
- ack jcraig
- 21:19:48 [Zakim]
- jcraig, you wanted to ask if the detailsfrom API Aaron mentioned can be extrapolated in all scenarios from the inverse details relationship, or are you proposing a new content
- 21:19:48 [Zakim]
- ... attribute `aria-detailsfrom`
- 21:19:50 [smockle]
- jamesn: I’m concerned this will lead to a proliferation of details, another instance of the `aria-controls` problem where it gets turned off.
- 21:20:42 [Matt_King]
- q+
- 21:20:45 [smockle]
- aaronlev: We will provide an additional hint to ATs
- 21:21:15 [smockle]
- aaronlev: We’ll expose all the information we have, then ATs can make the best decision for their users.
- 21:21:30 [Matt_King]
- q-
- 21:22:02 [smockle]
- aaronlev: Skipping to ::scroll-marker
- 21:22:48 [jcraig]
- Deep link to ::scroll-marker: https://docs.google.com/document/d/1lg5jC1vLSRBBLPHq-F0MnmQZfkuTUwaOKt7C2WImPCM/edit#heading=h.dl0t4by92h39
- 21:22:56 [smockle]
- flackr: :scroll-marker and scrolltarget creates a table of contents for your scroll, to support e.g. making a carousel.
- 21:23:59 [smockle]
- flackr: A group of navigation links, it should expose how many there are. You should be able to give a descriptive name.
- 21:24:18 [jamesn]
- q+ to ask is there a demo available?
- 21:24:33 [aardrian]
- Q+
- 21:24:55 [Matt_King]
- q+
- 21:25:03 [jamesn]
- ack me
- 21:25:03 [Zakim]
- jamesn, you wanted to ask is there a demo available?
- 21:25:10 [smockle]
- flackr: `scrollButton(direction)` lets you set up “next” and “previous” buttons for scrolling a carousel in a specific direction
- 21:25:25 [Jem]
- https://www.w3.org/WAI/ARIA/apg/patterns/carousel/
- 21:26:05 [Jem]
- https://github.com/flackr/carousel/tree/main/scroll-marker
- 21:26:06 [smockle]
- flackr: These APIs were designed to follow these demos.
- 21:26:12 [smockle]
- q?
- 21:26:19 [jamesn]
- ack aardrian
- 21:26:41 [smockle]
- aardrian: What was decorative?
- 21:27:06 [jamesn]
- q?
- 21:27:10 [smockle]
- flackr: “decorative” was the wrong word; it is functional.
- 21:27:11 [jamesn]
- ack Matt_King
- 21:27:35 [jcraig]
- q+
- 21:27:56 [cyns]
- Examples from https://github.com/w3c/csswg-drafts/issues/10912
- 21:27:57 [smockle]
- Matt_King: If that scroll marker group is auto-generated by the browser, how does the author control if they want tabs vs buttons? Do they have that control?
- 21:28:26 [cyns]
- The aria apg demo and @argyleink's carousel has the previous and next buttons next to each other in focus order despite the latter having them visually separated.
- 21:28:51 [cyns]
- https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-1-prev-next/
- 21:28:55 [smockle]
- flackr: The author of the site styles the scroller with a scroll marker group, containing `::scrollmarker` ← this pseudoelement is the control.
- 21:29:02 [cyns]
- https://gui-challenges.web.app/carousel/dist/
- 21:29:26 [smockle]
- Matt_King: How can you specify the semantic role of that scrollmarker?
- 21:29:41 [smockle]
- flackr: You cannot give a role to a pseudoelement; it’ll have one by default: button.
- 21:29:50 [smockle]
- Matt_King: But shouldn’t they have the tab role?
- 21:30:29 [jamesn]
- q?
- 21:30:59 [sarah]
- q+
- 21:31:05 [jcraig]
- q+ to reask my prior question about focusgroup,
- 21:31:09 [jamesn]
- ack jcraig
- 21:31:09 [Zakim]
- jcraig, you wanted to reask my prior question about focusgroup,
- 21:31:12 [smockle]
- Jamie: The scroller could have a role, and we could infer the scroll marker’s role from it
- 21:32:04 [smockle]
- jcraig: When you have a scrollmarker; how does this work with focus group or autofocus. Would you expect there is always a focus group for the container associated with the scroll marker?
- 21:32:32 [smockle]
- flackr: The scroll marker group is implicitly a focus group.
- 21:32:42 [smockle]
- jcraig: How would you define—when you scroll to this group—where keyboard/screen reader focus is supposed to land?
- 21:32:42 [cyns]
- Can someone who is in Zoom present this https://gui-challenges.web.app/carousel/dist/
- 21:33:11 [smockle]
- flackr: If you click e.g. the 3rd scroll marker, focus will remain on the marker.
- 21:34:01 [Jem]
- https://www.w3.org/WAI/ARIA/apg/patterns/carousel/
- 21:35:35 [smockle]
- jcraig: Can this widget be gamed to be something other than a scrollmarker?
- 21:35:46 [Jamie]
- q+ to note that setting next focusable element doesn't cover the screen reader UX
- 21:36:30 [smockle]
- jcraig: Not gaming the role, but repurposing the scroll marker concept to get some jumpy UI on the screen?
- 21:36:33 [jamesn]
- q?
- 21:36:52 [smockle]
- jcraig: e.g. a selection widget or form element
- 21:37:04 [smockle]
- sarah: Like if you needed an element to trigger focus mode
- 21:37:09 [aardrian]
- q+
- 21:37:12 [smockle]
- jcraig: Radio button jumps to mind
- 21:37:41 [smockle]
- flackr: I suppose there are examples where people use a carousel as a selection mechanism (e.g. levels in a game, Mario Kart tracks).
- 21:37:48 [jamesn]
- ack sarah
- 21:37:58 [jamesn]
- q+ sarah
- 21:38:06 [jcraig]
- qq+ sarah
- 21:38:13 [jcraig]
- ack jam
- 21:38:13 [Zakim]
- Jamie, you wanted to note that setting next focusable element doesn't cover the screen reader UX
- 21:38:38 [smockle]
- Jamie: From a screen reader perspective, setting the next focusable element doesn’t tell folks where to direct their attention now, before they press tab.
- 21:38:59 [smockle]
- flackr: It is similar to fragment navigation, which is in the HTML spec.
- 21:39:04 [cyns]
- q+
- 21:39:26 [smockle]
- Jamie: We need to make sure this gets mapped equivalently
- 21:39:26 [Matt_King]
- q?
- 21:39:27 [jamesn]
- ack sarah
- 21:39:27 [Zakim]
- sarah, you wanted to react to sarah
- 21:39:33 [jamesn]
- q- sarah
- 21:39:46 [smockle]
- sarah: If you query `document.activeElement` when one of the scroll marker pseudoelement is returned, what do you get back?
- 21:40:13 [smockle]
- flackr: Ideally, you’d get the pseudoelement, but that’s not supported yet, so the proposal is that you’ll get the scroller. When you focus any inner controls, the activeElement is the container.
- 21:40:19 [smockle]
- sarah: How can you programmatically focus one of those?
- 21:40:21 [smockle]
- flackr: You cannot.
- 21:40:39 [smockle]
- s/is returned/is focused
- 21:41:25 [ZoeBijl]
- +1 to sarah’s question
- 21:41:28 [smockle]
- sarah: Is there a reason to do this with pseudoelements?
- 21:41:57 [smockle]
- flackr: If you put anchor elements in a focus group, they take on the same qualities. The reason to do this with pseudoelements is to support generated content.
- 21:42:16 [jamesn]
- ack aardrian
- 21:42:19 [smockle]
- flackr: Pseudoelements is the only way to support the dynamic pagination use case.
- 21:43:09 [ZoeBijl]
- q+ to ask why is it the only way to support dynamic pagination?
- 21:43:30 [smockle]
- aardrian: HTML has mappings and queryable things. CSS doesn’t. That worries me. Has the team working on this looked at previous work: panels, panel sets?
- 21:44:29 [smockle]
- flackr: This is not trying to solve all things for a carousel component. This is a crucial part for a carousel, but it also has other use cases. It solves some of the semantic challenges: Sometimes authors present something that is a list of elements in one way on one device and another way on another device, like with media-queries.
- 21:44:55 [smockle]
- flackr: This allows you to change the visual presentation of your structural list into a carousel presentation. It is not trying to be a carousel. It is a table of contents for scrolling content.
- 21:45:11 [jamesn]
- ack cyns
- 21:45:28 [smockle]
- cyns: Are the next and previous buttons pseudoelements?
- 21:46:08 [smockle]
- cyns: Where should next and previous buttons be placed? There is inconsistency among demos.
- 21:46:21 [ZoeBijl]
- ack me
- 21:46:21 [Zakim]
- ZoeBijl, you wanted to ask why is it the only way to support dynamic pagination?
- 21:46:26 [jamesn]
- ack ZoeBijl
- 21:46:33 [smockle]
- cyns: My gut would be to put them together in the accessibility tree.
- 21:47:10 [smockle]
- ZoeBijl: Why would dynamic content require pseudoelements?
- 21:47:28 [smockle]
- flackr: This doesn’t require JS.
- 21:47:30 [cyns]
- should psuedoelements for previous/next buttons be together in focus order, even when they are visually before and after the content?
- 21:48:06 [smockle]
- aaronlev: Moving to CSS reading order; `reading-flow`
- 21:48:52 [smockle]
- aaronlev: You put this attribute on a container, then all elements will be re-ordered. Example values: `normal`, `flex-visual`.
- 21:49:17 [smockle]
- aaronlev: Only DOM siblings are reordered.
- 21:49:32 [jamesn]
- qv?
- 21:49:32 [aardrian]
- q+
- 21:49:59 [smockle]
- aaronlev: It reorders the accessibility tree to match the visual order, similar to `aria-owns`.
- 21:50:30 [jamesn]
- q+
- 21:50:46 [jamesn]
- ack aardrian
- 21:50:59 [smockle]
- aardrian: Which takes priority: ARIA or CSS?
- 21:51:15 [Rahim]
- q+
- 21:51:27 [smockle]
- aaronlev: ARIA.
- 21:51:51 [smockle]
- aardrian: `display: contents` is still an outlier because it blows away the box.
- 21:51:57 [jamesn]
- q-
- 21:52:12 [smockle]
- aardrian: I saw all the values this has—does this support absolute positioning and floats?
- 21:52:21 [smockle]
- aardrian: No, not currently.
- 21:52:33 [smockle]
- s/aardrian: No, not/aaronlev: No, not
- 21:53:03 [cyns]
- q+
- 21:53:05 [smockle]
- Jamie: There is an implementability concern for us
- 21:53:13 [jcraig]
- q+ to ask about a display:contents clarification of aaron's comment
- 21:53:35 [jamesn]
- ack Rahim
- 21:53:45 [jcraig]
- q+ to mention CSS/HTML is also meeting about this same issue right now!
- 21:53:54 [smockle]
- Rahim: What is the relationship between `reading-flow` and `order`
- 21:54:11 [smockle]
- Rahim: The `order` spec says it’s not to be used for anything beyond visual ordering.
- 21:54:59 [smockle]
- `order` changes visual order of flex children; `reading-flow: <something>` gives the accessibility tree the ability to match that
- 21:55:21 [jamesn]
- ack cyns
- 21:55:42 [smockle]
- cyns: Isn’t `float` usually siblings? Couldn’t `reading-flow` work with `float`?
- 21:55:49 [jamesn]
- cd jcraig
- 21:55:50 [jcraig]
- ack me
- 21:55:50 [Zakim]
- jcraig, you wanted to ask about a display:contents clarification of aaron's comment and to mention CSS/HTML is also meeting about this same issue right now!
- 21:55:55 [jamesn]
- ack jcraig
- 21:56:02 [smockle]
- aaronlev: `float` is usually legacy; I don’t think we should do anything about `float`
- 21:56:03 [jamesn]
- s/cd jcraig//
- 21:57:06 [smockle]
- jcraig: If you’ve got a `main` with a list with `display: contents`, then those list item children don’t get promoted into the child content of the `main`—then can `reading-flow` on `main` affect their order?
- 21:57:17 [jamesn]
- q?
- 21:57:21 [aardrian]
- aardrian
- 21:57:23 [aardrian]
- q+
- 21:57:39 [Jamie]
- q+ to ask where the non-DOM siblings go
- 21:57:53 [jamesn]
- zakim, close the queue
- 21:57:53 [Zakim]
- ok, jamesn, the speaker queue is closed
- 21:58:03 [smockle]
- aaronlev: DOM siblings can be reordered relative to each other.
- 21:58:04 [jamesn]
- ack aardrian
- 21:58:29 [jamesn]
- ack Jamie
- 21:58:29 [Zakim]
- Jamie, you wanted to ask where the non-DOM siblings go
- 21:58:37 [smockle]
- aardrian: I gave feedback: Let’s not do this in tables.
- 21:59:08 [jamesn]
- q?
- 21:59:57 [smockle]
- jcraig: This doc says that anything out-of-view is `inert`. That seems wrong.
- 22:02:31 [smockle]
- flackr: “outside of the particular scroll port” is better wording than “out-of-view”. Document updated.
- 22:02:53 [smockle]
- RRSAgent: make minutes
- 22:02:55 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html smockle
- 22:03:47 [ZoeBijl]
- topic: Interface Definition Language (IDL)
- 22:03:53 [ZoeBijl]
- [quick five minutes break]
- 22:05:35 [Rachel]
- Rachel has joined #aria
- 22:08:13 [Rachel]
- present+ Rachel_yager
- 22:08:21 [ZoeBijl]
- Rahim: good afternoon
- 22:09:04 [ZoeBijl]
- talking about aria from the html markup
- 22:09:11 [ZoeBijl]
- getting this right is important
- 22:09:15 [ZoeBijl]
- for a number of reasons
- 22:09:16 [ChrisCuellar]
- ChrisCuellar has joined #aria
- 22:09:19 [ZoeBijl]
- aria should be easy to use
- 22:09:21 [aardrian]
- aardrian has joined #aria
- 22:09:28 [ZoeBijl]
- thinking about accessibility in general
- 22:09:57 [ZoeBijl]
- this complex topic requires doing a bunch of groundwork
- 22:10:03 [ZoeBijl]
- so we’ll have a somewhat longer introduction
- 22:10:11 [ZoeBijl]
- at the half way mark we’ll pause for questions
- 22:10:19 [ZoeBijl]
- the story starts with idl in general
- 22:10:30 [ZoeBijl]
- [example of a button]
- 22:10:47 [ZoeBijl]
- code has a html button and some javascript setting and requesting attributes
- 22:11:16 [ZoeBijl]
- web interface definition language (idl) describes web APIs and their methords and properties
- 22:11:27 [ZoeBijl]
- browsers implement these so they’re interoperable
- 22:11:39 [ZoeBijl]
- for our button element it inherits from our buttons element
- 22:11:52 [ZoeBijl]
- similarly for the type property
- 22:11:55 [ZoeBijl]
- this is also a string
- 22:12:04 [ZoeBijl]
- it’s found in the IDL type definition?
- 22:12:25 [ZoeBijl]
- you might notice I’m using the “type” attribute property
- 22:12:35 [ZoeBijl]
- IDL and content attributes aren’t the same
- 22:12:53 [ZoeBijl]
- they’re two things that are represented by one thing
- 22:13:06 [ZoeBijl]
- highlighting some of the differences
- 22:13:09 [ZoeBijl]
- ??
- 22:13:23 [ZoeBijl]
- while IDL attributes are used to programmaticallt interact with the DOM and its nodes
- 22:13:33 [ZoeBijl]
- we use them as accessors directly
- 22:13:37 [ZoeBijl]
- importantly
- 22:13:46 [ZoeBijl]
- content attributes aren’t simply text
- 22:14:11 [ZoeBijl]
- for example the disabled idl attribute is true or false
- 22:14:23 [ZoeBijl]
- the content attribute is a string equal to these values
- 22:14:31 [ZoeBijl]
- content attributes are string based
- 22:15:03 [ZoeBijl]
- To summarize, content attributes are what is in the HTML markup
- 22:15:03 [ZoeBijl]
- They are string-based, are serialized as part of an HTML document and sent over the wire
- 22:15:03 [ZoeBijl]
- And interestingly, the Web IDL spec states that content attributes also serve as the “ultimate source of truth upon which the web platform is built”. Which makes sense because ultimately, a webpage is a text-based document and scripting/interactive behaviors should be separate and distinct from the text-based representation.
- 22:15:29 [ZoeBijl]
- IDL attributes, also called JS properties , enable more dynamic developer interaction with attributes and serve as a bridge between what’s in the HTML and its usage with JavaScript
- 22:15:42 [ZoeBijl]
- Although they’re different representation of a singular thing, It makes sense to keep content and IDL attribute values synchronized
- 22:15:42 [ZoeBijl]
- More formally, spec often states that an IDL attribute reflects its content attribute
- 22:15:53 [ZoeBijl]
- [showing some examples]
- 22:16:18 [ZoeBijl]
- the example is updating a input element’s id
- 22:16:30 [ZoeBijl]
- showing that now getting this attribute shows the updated value
- 22:17:04 [ZoeBijl]
- another example shows updating the type attribute via setAttribute
- 22:17:25 [ZoeBijl]
- in this example we’re doing the same but the value is being set to “foo”, an invalid value
- 22:17:39 [ZoeBijl]
- getAttribute("type") will default to text
- 22:18:13 [ZoeBijl]
- what if there’s no [type] content attribute on the element?
- 22:18:21 [ZoeBijl]
- Getting the content attribute returns null (i.e., the value we would expect for an attribute’s absence) although the IDL attribute still returns ‘text’
- 22:18:21 [ZoeBijl]
- It looks like browsers are using a default value of ‘text’ for the ‘type’ content attribute; this is better than rendering nothing in scenarios where ‘type’ is invalid or missing in the HTML markup
- 22:18:39 [ZoeBijl]
- In short, attribute validation is one of the things we get from IDL among other benefits which we’ll discuss shortly
- 22:18:59 [ZoeBijl]
- The “foo” IDL attribute doesn’t magically show up in the HTML markup as a content attribute
- 22:18:59 [ZoeBijl]
- In fact, it may be wrong to call it an IDL attribute at all because “foo” isn’t defined as a property of <input> elements via IDL, but I can use it, set it nonetheless like on any JavaScript object
- 22:19:20 [ZoeBijl]
- regarding reflection in html do different things
- 22:19:35 [ZoeBijl]
- - Some are true/false like disabled or inert attributes
- 22:19:35 [ZoeBijl]
- - Some attributes are enumerated, i.e., they have a set of permissible values. For example, the ‘type’ attribute for <input>
- 22:19:35 [ZoeBijl]
- - Some attributes are simply strings, such as “id”
- 22:19:35 [ZoeBijl]
- - Some attributes are numeric, such as colspan and rowspan, and so on and so forth
- 22:19:40 [ZoeBijl]
- The takeaway here is that content attributes can be categorized into types, and IDL attributes definitely have their own types as well
- 22:19:51 [ZoeBijl]
- I like to think of content attribute types as an abstract description of what an attribute’s values can be and IDL attributes as the API type in a programming context
- 22:20:13 [ZoeBijl]
- For example, title has no value constraint but is implemented as a DOMString (basically a string) for its IDL type, disabled is a boolean logically and implemented as such for its IDL type
- 22:20:14 [ZoeBijl]
- classList represents space-separated tokens but implemented as DOMTokenList and colspan represents a non-negative integer but implemented as unsigned long
- 22:20:23 [ZoeBijl]
- For the purposes of reflection, the content attribute type and IDL attribute type are both important
- 22:20:28 [ZoeBijl]
- Let’s take a look at all of the content attributes in the previous slide and see reflection works for each of them
- 22:20:37 [ZoeBijl]
- The ‘title’ content attribute has no value constraint, and its IDL attribute type is DOMString
- 22:20:52 [ZoeBijl]
- When the 'title' content attribute is missing, it reflects as the empty string
- 22:20:57 [ZoeBijl]
- When the content attribute is set to the empty string, it reflects as the same
- 22:21:00 [ZoeBijl]
- And when the content attribute is set to a value such as “a large button”, it reflects “a large button” for the IDL attribute
- 22:21:07 [ZoeBijl]
- The ‘disabled’ content attribute is a boolean, and its IDL attribute type is also boolean
- 22:21:13 [ZoeBijl]
- If the ‘disabled’ content attribute is present without a value or set to the empty string, or set to any string for that matter, it reflects as “true”
- 22:21:21 [ZoeBijl]
- If it’s missing, the content attribute returns null and the IDL attribute value is false
- 22:21:40 [ZoeBijl]
- We saw in previous slides how the ‘type’ attribute for <input> elements reflect
- 22:21:40 [ChrisCuellar]
- ChrisCuellar has joined #aria
- 22:21:43 [ZoeBijl]
- As an enumerated attribute that is a DOMString, its IDL attribute can only be set to limited, known values such as text, checkbox or radio.
- 22:21:50 [ZoeBijl]
- And, enumerated attributes are special because they have what is called a missing value default and invalid value default state which handles what to do for missing or invalid values.
- 22:22:00 [ZoeBijl]
- When we supplied an <input> with type=”foo” in the earlier example, the browser defaults to a value of “text” which is the invalid value default for this attribute
- 22:22:09 [ZoeBijl]
- ariaActiveDescendantElement is the only ARIA IDL attribute that reflects as nullable Element
- 22:22:19 [ZoeBijl]
- which means that when the attribute is missing or set to the empty string, it returns null
- 22:22:25 [ZoeBijl]
- And when the content attribute is set to a valid ‘id’, it returns an element node reference
- 22:22:33 [ZoeBijl]
- The ‘popover’ attribute is also an enumerated attribute but it reflects as a nullable DOMString?; where IDL attribute types have a question mark, this means that they support a special value of “null”
- 22:22:45 [ZoeBijl]
- that’s what the spec means by nullable
- 22:22:53 [ZoeBijl]
- it means that it supports this “null” value
- 22:22:58 [ZoeBijl]
- If a popover attribute is missing and returns null, this is semantically important; i.e., the null state means the element has no popover state
- 22:23:08 [ZoeBijl]
- The ‘type’ attribute, on the other hand, reflects as a non-nullable DOMString (that is, without the question mark) because null isn’t a permissible value for ‘type’. An input element having no type doesn’t make sense, but an element having no popover is logical
- 22:23:29 [ZoeBijl]
- You’ll notice that nullable DOMString reflection for enumerated attributes works similar to non-nullable DOMString reflection with the exception of the IDL attribute reflecting null when the content attribute is missing, so we can easily detect an absent value via “null”
- 22:23:45 [ZoeBijl]
- So generally, enumerated attributes can reflect as either DOMString or nullable DOMString?, can be limited to known values and have two special states: missing/invalid value defaults
- 22:23:56 [ZoeBijl]
- For nullable DOMString reflection, the flexibility of allowing a “null” value comes at the cost of requiring that the content attribute is enumerated which makes logical sense because the null value has a meaning, like no popover state
- 22:24:35 [ZoeBijl]
- when a developer tries to set a null value to a non-nullable attribute
- 22:24:43 [ZoeBijl]
- IDL will delete the attribute?
- 22:24:46 [ZoeBijl]
- Non-nullable DOMString reflection such as id or title take any value and simply returns it or the empty string
- 22:24:54 [ZoeBijl]
- a couple of other examples
- 22:24:57 [ZoeBijl]
- classList represents space-separated tokens and IDL type is DOMTokenList
- 22:25:01 [ZoeBijl]
- When the content attribute contains one or more classes, it reflects this as a DOMTokenList
- 22:25:10 [ZoeBijl]
- And when the content attribute is the empty string or missing, it returns null for the content attribute and an empty DOMTokenList for the IDL attribute
- 22:25:23 [ZoeBijl]
- And lastly, as a numeric type, colspan for <table>’s td element is a non-negative integer that has an IDL type of unsigned long
- 22:25:30 [ZoeBijl]
- You can see the benefit of IDL reflection here because any content attribute value that isn’t a positive integer (when parsed), defaults to a value of 1 for IDL purposes
- 22:25:49 [ZoeBijl]
- But I would note here that numeric IDL types such as Long/Double aren’t nullable because this aligns with how numeric types are treated in programming languages (by using a default value of 0 or 1 or NaN, not a number)
- 22:25:58 [ZoeBijl]
- So, that’s an overview of common reflection models for some HTML attributes
- 22:26:18 [ZoeBijl]
- I’ve mentioned all of these except the last row here which is FrozenArray<E> reflection, i.e., an array of element nodes references such as activeElement or ariaDescribedByElements so their reflection is also unique
- 22:26:43 [ZoeBijl]
- I definitely bears noting that reflection is well-defined in HTML spec and other languages should lean on it where possible which includes ARIA
- 22:26:53 [ZoeBijl]
- Alright, my presentation is called ARIA IDL and we haven’t even talked about it yet!
- 22:27:04 [ZoeBijl]
- But level-setting on HTML reflection, IDL attribute types and some of the nuances of different reflection models will definitely help with the upcoming discussion
- 22:27:20 [ZoeBijl]
- here’s a screenshot of an ARIA IDL definition block
- 22:27:20 [jcraig]
- Rahim's slides are here, by the way: https://docs.google.com/presentation/d/1U31P2w8PeEb8w3TKnCVpSjfVA7IZMgCKOoh6_fvLQI0/edit#slide=id.g28b01e34d8e_0_100
- 22:27:42 [ZoeBijl]
- in this block you’ll notice that it’s comprised of only attributes at present, and I think the upcoming ariaNotify API will be the first operation or method we define for ARIA IDL
- 22:28:00 [ZoeBijl]
- And importantly, currently, every single ARIA attribute reflects as one of three types:
- 22:28:26 [ZoeBijl]
- - Nullable Element
- 22:28:26 [ZoeBijl]
- - Nullable FrozenArray<E> (which takes an element)
- 22:28:26 [ZoeBijl]
- - Nullable DOMString
- 22:28:26 [ZoeBijl]
- Let’s walk through the reflection model for each
- 22:28:29 [ZoeBijl]
- ariaActiveDescendantElement is the only ARIA IDL attribute that reflects as nullable Element
- 22:28:33 [ZoeBijl]
- And when the content attribute is set to a valid ‘id’, it returns an element node reference
- 22:28:43 [ZoeBijl]
- All of the ARIA attributes which take a set of IDRefs such as ariaDescribedByElements, ariaLabelledbyElements, reflect as nullable FrozenArray<E>
- 22:28:57 [ZoeBijl]
- This means that when the content attribute is missing, it turns null; when its set to the empty string it returns an empty array and when it’s set to one or more valid IDREFs, it returns an array of element node references
- 22:29:09 [ZoeBijl]
- And thirdly, and most importantly, the overwhelming majority of ARIA attributes reflect as nullable DOMString
- 22:29:28 [ZoeBijl]
- When the content attribute is missing, for example aria-atomic, aria-expanded, we get null on the IDL side; when it’s set to the empty string we get the empty string and when it’s set to any string value, we get exactly that string value (such as the string “true” or even the string “undefined”) for the IDL attribute
- 22:29:46 [ZoeBijl]
- This accords with ARIA spec that essentially states missing ARIA content attributes should reflect as null or the literal string value of the content attribute
- 22:30:09 [ZoeBijl]
- There’s a problem here though; because I just said that a nullable DOMString? IDL attribute must be enumerated. As it states in the HTML spec.
- 22:30:10 [ZoeBijl]
- However, ARIA attributes are not enumerated
- 22:30:20 [ZoeBijl]
- Since ARIA attributes are not enumerated, like <input>’s ‘type’ or popover attributes, consequently, they don’t align with HTML’s reflection model and spec for nullable DOMString?
- 22:30:28 [ZoeBijl]
- However, there are a number of very good reasons why ARIA uses and in fact requires nullable DOMString?
- 22:30:50 [ZoeBijl]
- First, the absence of many ARIA content attributes has meaning which means “null” is semantically important; e.g., a missing aria-checked means that the element doesn’t support being checked, which is different than aria-checked=false which means an element supports checkedness but is not currently checked
- 22:31:12 [ZoeBijl]
- Second, as a consequence of this, numeric ARIA values have defaults which are role-specific; e.g., on an element with role=”slider” missing aria-valuenow, the default involves calculating valuemin/valuemax. A numeric IDL type such as Unsigned Long, wouldn’t work because a single default value across all roles wouldn’t universally hold true
- 22:31:20 [ZoeBijl]
- And since we can’t do role-specific reflection with the HTML reflection model, nullable DOMString seems like the next best thing
- 22:31:29 [ZoeBijl]
- Nullable DOMString reflection additionally means that a11y APIs can handle complex validation downstream since the browser is not performing any further validation
- 22:31:39 [ZoeBijl]
- either it’s null or the string value
- 22:31:50 [ZoeBijl]
- And lastly, Nullable DOMString reflection works for ARIA attributes that are unconventional (for lack of a better word) in the values they take, e.g., ariaRelevant or ariaKeyShortcuts
- 22:32:07 [ZoeBijl]
- there are strong reasons for nullable DOMString reflection, it does introduce several challenges that may not make it the most optimal solution long-term
- 22:32:15 [ZoeBijl]
- First, the majority of ARIA attributes reflect as nullable DOMString although they are not enumerated attributes, which means that ARIA IDL does not fully align with HTML reflection of nullable DOMString
- 22:32:27 [ZoeBijl]
- As such, there is misalignment between ARIA and HTML and a lack of clarity between what undefined a value means from both a spec and JavaScript perspective
- 22:32:31 [ZoeBijl]
- Another challenge is that ARIA isn’t currently able to take advantage of robust feature detection
- 22:32:43 [ZoeBijl]
- For example, if aria-invalid had a new attribute value, the browser could specify what happens as part of invalid value default or a fallback if the user agent doesn’t support the new value. Think of <input> ‘type’ property and how it falls back to “text”
- 22:33:12 [ZoeBijl]
- This links into the general challenge of general lack of support for HTML-style IDL validation, such as missing/invalid value default for enumerated attributes, and default value for numeric attributes
- 22:33:19 [ZoeBijl]
- There’s also ambiguity around why numeric ARIA attributes such as aria-valuemin/valuemax reflect as strings
- 22:33:23 [ZoeBijl]
- as a devleoper
- 22:33:31 [ZoeBijl]
- you might intuitive think they’re numbers
- 22:33:33 [ZoeBijl]
- but they are strings
- 22:33:35 [ZoeBijl]
- at present
- 22:33:50 [ZoeBijl]
- And lastly, what does ARIA do with future attributes? Should they continue reflecting as nullable DOMString?, could they become truly enumerated attributes, and if new attributes reflect like HTML, should current attributes be revisited to align with the best possible IDL type?
- 22:34:01 [ZoeBijl]
- it creates a divergence ??
- 22:34:10 [ZoeBijl]
- a future where we want to have a numeric type
- 22:34:29 [ZoeBijl]
- Resolving some or all of these challenges would have benefits, among them simpler developer usage of ARIA, feature detection and more robust attribution validation that aligns with ARIA’s primary host language HTML.
- 22:34:38 [ZoeBijl]
- So, to this end, let’s wrap up by taking a look at some proposals that James Craig and I came up with for improving ARIA IDL
- 22:34:48 [ZoeBijl]
- These proposals are roughly ranked from worst to best, or perhaps least desirable/tenable to most
- 22:34:56 [ZoeBijl]
- there’s about six of them
- 22:35:01 [ZoeBijl]
- The first proposed solution involves removing role-specific default values on a per-attribute basis
- 22:35:11 [ZoeBijl]
- For this proposal, attributes like aria-orientation, aria-selected and aria-pressed could always default to “undefined” regardless of the element’s role
- 22:35:27 [ZoeBijl]
- Benefit of doing that we’re going to align with the HTML spec pretty well
- 22:35:46 [ZoeBijl]
- We would have our missing attribute default
- 22:35:56 [ZoeBijl]
- it would also simplify some of the validation
- 22:35:59 [ZoeBijl]
- the draw back
- 22:36:12 [ZoeBijl]
- it doesn’t necesarily align with ??
- 22:36:21 [ZoeBijl]
- it’s unclear how this impacts the user experience
- 22:36:34 [ZoeBijl]
- the spec currently says that ??
- 22:37:01 [ZoeBijl]
- this one definitely is probably a non starter
- 22:37:11 [ZoeBijl]
- For the second proposal, the ARIA spec could align with HTML reflection with role-specific IDL
- 22:37:20 [ZoeBijl]
- For example, if aria-orientation is missing, the attribute’s reflection model would first compute the role, and determine the value of aria-orientation depending on the role
- 22:37:39 [ZoeBijl]
- Here’s a high-level view of how that could work
- 22:37:41 [keithamus]
- q?
- 22:37:44 [ZoeBijl]
- it could be defined as an enumerated attribute with IDL type of nullable DOMString
- 22:38:07 [ZoeBijl]
- We could have multiple keywords that map to a a single state
- 22:38:20 [ZoeBijl]
- the missing value default could be called auto
- 22:38:41 [ZoeBijl]
- This proposals is definitely more easily said than done
- 22:38:46 [ZoeBijl]
- the benefits are pretty clear
- 22:38:53 [ZoeBijl]
- easier inter?? between aria and html
- 22:39:04 [ZoeBijl]
- we would definitely align clsoer with HTML reflection
- 22:39:08 [ZoeBijl]
- s/clsoer/closer/
- 22:39:24 [ZoeBijl]
- it would be relatively simple to continue using a similar model
- 22:39:27 [ZoeBijl]
- the main drawback
- 22:39:34 [ZoeBijl]
- that jcraig educated me on
- 22:39:54 [ZoeBijl]
- implementing role specific ideal would require execution of accessibility runtime code
- 22:40:07 [ZoeBijl]
- perhaps it could result in some sort of circular refence
- 22:40:22 [ZoeBijl]
- jcraig: it could result in major reqrites in browsers
- 22:40:28 [ZoeBijl]
- s/reqrites/rewrites/
- 22:40:37 [ZoeBijl]
- Rahim: other drawbacks
- 22:40:43 [ZoeBijl]
- ??
- 22:40:44 [ZoeBijl]
- ???
- 22:40:52 [ZoeBijl]
- at the browser level
- 22:41:10 [ZoeBijl]
- webkit aria-orientation detects ??
- 22:41:35 [ZoeBijl]
- ARIA spec could align with HTML reflection without role-specific IDL. So, on an attribute-by-attribute basis, we would determine which attribute could be converted to an appropriate IDL type and reflect as the best possible type
- 22:41:40 [ZoeBijl]
- A good example of this is aria-modal which could be converted easily to an enumerated attribute
- 22:41:55 [ZoeBijl]
- Note that aria-modal has no default value which makes it relatively easy to align with enumerated, nullable DOMString? Reflection
- 22:42:01 [ZoeBijl]
- missing value default would be false
- 22:42:08 [ZoeBijl]
- invalid value default would also be false
- 22:42:34 [ZoeBijl]
- some attributes will require default values that are role specific
- 22:43:07 [ZoeBijl]
- another benefit all aria idl attributes could have standard processing model
- 22:43:12 [ZoeBijl]
- which would simplify specs
- 22:43:34 [ZoeBijl]
- the drawbacks are that we have role specific needs for idl reflections
- 22:44:02 [ZoeBijl]
- For proposal #4, the ARIA WG could a way formalization of reflection in another spec (such as HTML).
- 22:44:33 [ZoeBijl]
- s/a way/await/
- 22:44:46 [ZoeBijl]
- there’s work that’s taking place, Anna, Domenic
- 22:44:55 [ZoeBijl]
- it would take into account ARIA’s needs
- 22:45:04 [jcraig]
- s/Anna/AnneVK/
- 22:45:04 [ZoeBijl]
- s/Anna/Anne/
- 22:45:17 [keithamus]
- q+
- 22:45:26 [ZoeBijl]
- HTML spec could be the place where all of this is specified and quantified?
- 22:45:41 [spectranaut_]
- q?
- 22:45:45 [ZoeBijl]
- propsal #5 we could keep what we have
- 22:45:49 [ZoeBijl]
- For proposal #5, ARIA could keep string reflection as is and new IDL attributes for some attributes
- 22:45:49 [spectranaut_]
- zakim, open queue
- 22:45:49 [Zakim]
- ok, spectranaut_, the speaker queue is open
- 22:45:55 [spectranaut_]
- q+ keithamus
- 22:45:58 [ZoeBijl]
- A great example of this would be the class content attribute which actually has two corresponding IDL attributes
- 22:46:04 [ZoeBijl]
- this is already done in HMTL
- 22:46:09 [ZoeBijl]
- s/HMTL/HTML/
- 22:46:24 [ZoeBijl]
- if i want to add class i would have to concat the value
- 22:46:33 [ZoeBijl]
- and removing it would require string manipulation
- 22:46:45 [ZoeBijl]
- classlist already solves this
- 22:47:02 [ZoeBijl]
- a benefit is allows ARIA to keep current string-reflected attributes as is
- 22:47:31 [ZoeBijl]
- like aria-valuemin could have a new value
- 22:47:34 [ZoeBijl]
- like a min value
- 22:47:39 [ZoeBijl]
- New attributes will benefit from HTML-style IDL (e.g., enumerated, numeric)
- 22:47:45 [ZoeBijl]
- drawbacks
- 22:47:46 [cyns]
- cyns has joined #aria
- 22:47:50 [ZoeBijl]
- May introduce confusion on ARIA JS usage since multiple IDL attributes can map to a single content attribute
- 22:47:53 [ZoeBijl]
- May complicate implementations
- 22:48:00 [Jamie]
- s/a new value/a new IDL attribute/
- 22:48:08 [ZoeBijl]
- And finally, proposal #6, ARIA could keep string reflection exactly as is without making any change
- 22:48:12 [cyns]
- q?
- 22:48:20 [ZoeBijl]
- benefits are that it currently works
- 22:48:23 [Jamie]
- s/like a min value/like ariaMinValueNumber/
- 22:48:23 [ZoeBijl]
- requires minimal work
- 22:48:27 [Matt_King]
- q?
- 22:48:37 [ZoeBijl]
- allows for role-specific validation to occur downstream at AT layer
- 22:48:41 [cyns]
- q+
- 22:48:45 [Matt_King]
- q+
- 22:48:53 [ZoeBijl]
- drawbacks
- 22:48:55 [ZoeBijl]
- May not be ideal to have fully customized reflection for ARIA from IDL purist perspective
- 22:49:01 [ZoeBijl]
- Doesn’t fully resolve undefined confusion
- 22:49:04 [ZoeBijl]
- Confusion on IDL treatment for new ARIA attributes
- 22:49:59 [ZoeBijl]
- [aria-notify session will start ten minutes late]
- 22:50:46 [hdv]
- ack keith
- 22:50:48 [ZoeBijl]
- keithamus: i had a question around the implementation difficulty of computed reflections
- 22:50:53 [ZoeBijl]
- are we saying this is not tennable?
- 22:51:06 [ZoeBijl]
- because of the disconnect of the aria attributes and IDL?
- 22:51:12 [ZoeBijl]
- could we get a lazy getter?
- 22:51:25 [ZoeBijl]
- struggling with the implementation difficulty side?
- 22:51:41 [ZoeBijl]
- jcraig: role computation in most a11y runtime is done in the accessibility code
- 22:51:45 [ZoeBijl]
- s/a11y/accessibility/
- 22:51:53 [ZoeBijl]
- browsers are tuned to be as fast as possible
- 22:52:09 [ZoeBijl]
- what this takes is to carve out all places where we’re computing these roles
- 22:52:19 [ZoeBijl]
- and take it out of the accessibility runtime
- 22:52:28 [ZoeBijl]
- there’s a lot of risk
- 22:52:40 [ZoeBijl]
- Jamie: it’s not only aria roles but also implicit role
- 22:52:50 [ZoeBijl]
- that can impact how the defaults can be computed
- 22:53:00 [ZoeBijl]
- jcraig: there’s heuristics to be considered too
- 22:53:36 [ZoeBijl]
- it’s a huge amount of work
- 22:53:38 [ZoeBijl]
- it’s possible
- 22:53:45 [ZoeBijl]
- but there’s a risk
- 22:54:09 [ZoeBijl]
- keithamus: another thing to clarify is that we don’t have to map missing and invalid attributes
- 22:54:17 [ZoeBijl]
- they’re optional to ?? attributes
- 22:54:23 [ZoeBijl]
- we could do this in smaller steps
- 22:54:33 [ZoeBijl]
- where we could say go through all the domstring? idl
- 22:54:39 [ZoeBijl]
- map the missing ?? to all ??
- 22:54:44 [ZoeBijl]
- so filling the gaps
- 22:54:53 [ZoeBijl]
- jcraig: yea for all the ?? it could be possible to continue that way
- 22:55:03 [ZoeBijl]
- keithamus: it sounds like folks aren’t sure on the value add
- 22:55:09 [Jem]
- This is the discussion of paradigm shift.
- 22:55:10 [ZoeBijl]
- the reflection is a very important education tool
- 22:55:20 [jcraig]
- s/the ?? it could /the enumerated attributes it could /
- 22:55:30 [ZoeBijl]
- it helps, it’s a run time validation, you can see what ?? by just noodling in the accessibility inspector
- 22:55:46 [jcraig]
- qv?
- 22:55:56 [ZoeBijl]
- to validate your web application, which relies on computed values, is important for weba pps to test their ??
- 22:55:57 [Jem]
- q?
- 22:56:28 [ZoeBijl]
- Rahim: ?? that’s not formalised in the HTML spec
- 22:56:47 [ZoeBijl]
- so yes it could be that there might be a day where you can simply ?? as a nullable domstring
- 22:56:58 [ZoeBijl]
- it doesn’t circumvent the issue of calculating a ??
- 22:57:11 [ZoeBijl]
- in my mind i think that having the ability to know what the role is
- 22:57:18 [ZoeBijl]
- makes what aria ?? so difficult
- 22:57:27 [spectranaut_]
- ack cyns
- 22:57:29 [ZoeBijl]
- cyns: a lot of great inormation
- 22:57:32 [ZoeBijl]
- thanks for explaining
- 22:57:44 [ZoeBijl]
- what i didn’t get is what the problem is that we’re trying to solve
- 22:57:50 [ZoeBijl]
- is it just html or does it face users?
- 22:58:08 [ZoeBijl]
- Rahim: the number one challenge there is this alignment with how ARIA currently reflects
- 22:58:26 [ZoeBijl]
- when Anne and I discussed it we called it a bug
- 22:58:34 [ZoeBijl]
- from an IDL purist persepctive aria is doing something different from what the html spec allows
- 22:58:48 [ZoeBijl]
- using attributes from the authors perspective ??
- 22:58:49 [jcraig]
- qq+ to respond to cyns ?
- 22:58:59 [ZoeBijl]
- but aria-modal is a string? why? it’s confusing to authors
- 22:59:15 [ZoeBijl]
- the number one benefit is to have developers have a much simpler understanding of aria
- 22:59:28 [ZoeBijl]
- use it in a simpler and easy to understand way
- 22:59:38 [ZoeBijl]
- cyns: so the issue is that it doesn’t match html?
- 22:59:39 [ZoeBijl]
- jcraig: no
- 22:59:47 [ZoeBijl]
- there are implementer benefits
- 22:59:53 [ZoeBijl]
- like copying stuff from idl
- 23:00:01 [ZoeBijl]
- keithamus: like code generation?
- 23:00:03 [ZoeBijl]
- jcraig: yea
- 23:00:23 [ZoeBijl]
- which would be more reliable if we write this implementation
- 23:00:34 [ZoeBijl]
- one of the things we can agree on here is that there are ??
- 23:00:43 [spectranaut_]
- q?
- 23:00:43 [ZoeBijl]
- because we have these things in the spec before html did it
- 23:00:46 [spectranaut_]
- ack jcraig
- 23:00:46 [Zakim]
- jcraig, you wanted to react to cyns to respond to cyns ?
- 23:00:48 [ZoeBijl]
- before we had idl at all
- 23:01:01 [ZoeBijl]
- maybe we can agree to not break these patterns in the future
- 23:01:10 [ZoeBijl]
- cyns: ????
- 23:01:16 [ZoeBijl]
- keithamus: add our own reflection rule
- 23:01:21 [ZoeBijl]
- the same but different
- 23:01:24 [Jamie]
- q+ to ask: can we do any of these things without backwards compatibility breakage?
- 23:01:30 [ZoeBijl]
- which is used exclusively for aria properties
- 23:01:53 [ZoeBijl]
- cyns: our perhaps html didn’t consider all the use cases
- 23:01:58 [ZoeBijl]
- jcraig: it doesn’t ?? but it does ??
- 23:02:05 [ZoeBijl]
- cyns: what’s html stopping from doing that
- 23:02:21 [ZoeBijl]
- jcraig: that would ?? that would give us the most benefit in the long term
- 23:02:39 [ZoeBijl]
- cyns: that helps
- 23:02:43 [jcraig]
- q?
- 23:02:48 [ZoeBijl]
- but i still don’t quite understand the issue at play here
- 23:03:00 [ZoeBijl]
- Rahim: with svg
- 23:03:05 [ZoeBijl]
- i’m not sure ??
- 23:03:11 [ZoeBijl]
- i think there’s some nuance here
- 23:03:17 [spectranaut_]
- ack Matt_King
- 23:03:31 [ZoeBijl]
- Matt_King: i love all the pro’s and con’s
- 23:03:33 [ZoeBijl]
- there were a few downsides to number 5
- 23:03:35 [jcraig]
- s/that would ?? that would /being able to add a IDL attr by role rather than by element type /
- 23:03:39 [ZoeBijl]
- min number and max number
- 23:03:43 [jcraig]
- rrsagent, make minutes
- 23:03:44 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html jcraig
- 23:03:50 [ZoeBijl]
- could there be a 5.1?
- 23:03:58 [ZoeBijl]
- where you can get past that developer confusion?
- 23:04:12 [ZoeBijl]
- Rahim: great question
- 23:04:20 [ZoeBijl]
- keithamus: there’s precedence for that
- 23:04:28 [ZoeBijl]
- there’s idls for input value
- 23:04:34 [ZoeBijl]
- because input has different types
- 23:04:52 [ZoeBijl]
- value as number will parse it differently from value as string
- 23:04:56 [ZoeBijl]
- we could do the same thing here
- 23:05:01 [ZoeBijl]
- i dislike it personally
- 23:05:02 [jcraig]
- s/most benefit in the long term/most benefit in the long term but I can't speak to how complex that implementation would be in IDL/
- 23:05:08 [spectranaut_]
- q?
- 23:05:09 [ZoeBijl]
- it aids to developer confusion rather than fix it
- 23:05:32 [ZoeBijl]
- Jamie: are we proposing changing the existing ?? attributes?
- 23:05:39 [ZoeBijl]
- browsers are all shipping
- 23:05:43 [ZoeBijl]
- s/??/IDL/
- 23:05:59 [ZoeBijl]
- but I don’t think we can change the existing idl attributes without breaking the web
- 23:06:15 [ZoeBijl]
- Rahim: i don’t think we need to change the attribute types
- 23:06:27 [ZoeBijl]
- it wouldn’t involve underlying attribute types
- 23:06:40 [ZoeBijl]
- Jamie: as soon as we change ?? we need to change the underlying once
- 23:06:53 [ZoeBijl]
- jcraig: yea even just the enumerated ones
- 23:07:03 [ZoeBijl]
- Jamie: we could support token ??
- 23:07:20 [ZoeBijl]
- jcraig: ???
- 23:07:37 [ZoeBijl]
- Jamie: it could be that html exposes semantics that we don’t know about here
- 23:07:43 [Jem]
- q?
- 23:07:54 [ZoeBijl]
- sometimes html specifies semantics that aren’t defined in aria?
- 23:08:07 [ZoeBijl]
- unless the accessibility layer is running we don’t know those things
- 23:08:12 [ZoeBijl]
- jcraig: html always wins
- 23:08:18 [ZoeBijl]
- Jamie: aria-disabled
- 23:08:24 [ZoeBijl]
- if we said the default for that is false
- 23:08:33 [ZoeBijl]
- ????
- 23:08:39 [ZoeBijl]
- jcraig: aria-disabled is a @@@
- 23:08:59 [ZoeBijl]
- we never defer to aria in that particular case
- 23:09:19 [ZoeBijl]
- if button doesn’t have disabled but does have aria-disabled it’s not disabled?
- 23:09:28 [Jem]
- q+
- 23:09:44 [jcraig]
- ack jamie
- 23:09:45 [spectranaut_]
- ack Jamie
- 23:09:45 [Zakim]
- Jamie, you wanted to ask: can we do any of these things without backwards compatibility breakage?
- 23:09:49 [jcraig]
- ack Jem
- 23:09:55 [ZoeBijl]
- Jem: i like the idea
- 23:10:05 [ZoeBijl]
- it would be good if things were easier
- 23:10:16 [ZoeBijl]
- but if there’s only one thing we can work on
- 23:10:22 [ZoeBijl]
- which would it be from your proposals
- 23:10:30 [ZoeBijl]
- Rahim: it would be converting all the attributes
- 23:10:41 [ZoeBijl]
- that way we get defaults, validation, feature detection
- 23:10:59 [ZoeBijl]
- jcraig: all of the enumerated attributes that do not have a default specified somewhere
- 23:11:09 [ZoeBijl]
- cyns: was it one of your numbered options
- 23:11:26 [ZoeBijl]
- Rahim: it’s on slide #77
- 23:11:29 [jcraig]
- s/converting all the attributes/converting all the enumerated attributes that do not have a role-specific default defined somewhere/
- 23:11:56 [ZoeBijl]
- jcraig: there’s a few things we can do further down the line
- 23:12:03 [ZoeBijl]
- maybe we don’t want role specific defaults?
- 23:12:07 [Doug]
- Doug has joined #aria
- 23:12:13 [ZoeBijl]
- ?? in addition to the string
- 23:12:21 [ZoeBijl]
- we can decide those individually
- 23:12:36 [ZoeBijl]
- Rahim: will work on PR
- 23:12:43 [ZoeBijl]
- hoping to get that reviewed
- 23:20:29 [alisonmaher]
- alisonmaher has joined #aria
- 23:41:24 [Adam_Page]
- present+
- 23:41:25 [Jem]
- https://github.com/w3c/aria/wiki/TPAC-2024-ARIA-Meetings
- 23:41:30 [sarah]
- sarah has joined #aria
- 23:41:49 [ethanjv]
- ethanjv has joined #aria
- 23:43:17 [smockle]
- RRSAgent: make minutes
- 23:43:18 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/23-aria-minutes.html smockle
- 23:43:32 [smockle]
- Topic: ariaNotify
- 23:45:35 [Jamie]
- Jamie has joined #aria
- 23:45:54 [alisonmaher]
- https://docs.google.com/document/d/1gwTSfZeT3xIB9k1nVgoLm0Cg64eODGHBDcvB-42xQ4k/edit?usp=sharing
- 23:46:07 [sarah]
- scribe: sarah
- 23:46:11 [aardrian]
- aardrian has joined #aria
- 23:46:13 [jocelyntran]
- jocelyntran has joined #aria
- 23:46:16 [aardrian]
- Present+
- 23:46:21 [sarah]
- alisonmaher: the document has a summary of (everything)
- 23:46:31 [cyns]
- cyns has joined #aria
- 23:46:37 [sarah]
- alisonmaher: ariaNotify is a new api that gives devs a tool in the toolbox that allows them to send notifications that are informative to AT users
- 23:46:51 [nathan]
- nathan has joined #aria
- 23:47:03 [sarah]
- alisonmaher: for example it's useful for confirmation of action like bold on/off, or if there's a keyboard shortcut available. There are some new features like queing and flushing
- 23:47:06 [sabidussi_marco]
- sabidussi_marco has joined #aria
- 23:47:26 [sarah]
- alisonmaher: today there's only live regions, which works well for live updating content, but it's also used for things like offscreen live regions which we want to use ariaNotify for
- 23:47:32 [sarah]
- alisonmaher: github has some demos to share
- 23:47:45 [sarah]
- keithamus: we've been developing a polyfill [echo echo]
- 23:47:57 [jyasskin]
- jyasskin has joined #aria
- 23:48:02 [jyasskin]
- present+
- 23:48:30 [bkardell_]
- present+
- 23:49:47 [sarah]
- keithamus: demo'ing NVDA on an example page
- 23:50:17 [sarah]
- keithamus: let's actually demo this thing
- 23:50:37 [sarah]
- keithamus: we've developed a polyfill for ariaNotify, it uses the offscreen live region hack but it exposes the API in the same way we'd expect the browser to
- 23:50:54 [sarah]
- keithamus: we have some new ideas around user experience that don't fall into the existing features of HTML
- 23:51:13 [sarah]
- keithamus: [demo'ing typing text into a textbox that shows a ghost autofill]
- 23:51:36 [sarah]
- keithamus: this is the kind of thing we're interested in powering with ariaNotify. One key area is the availability to interrupt. So as I type in, you can hear it's interrupting
- 23:52:10 [sarah]
- keithamus: we've also added this playground page, and here you can queue a set of notifications with different properties, and you can play the entire queue to understand how it'll interact with the new API
- 23:52:23 [sarah]
- keithamus: it's helpful for us developing the polyfill, but it's also helpful this session
- 23:52:51 [sarah]
- keithamus: this is running natively. in chrome, the feature flags are turned on. We're shipping this to a small select number of users on github where we're using the ariaNotify polyfill
- 23:53:07 [sarah]
- keithamus: I'm happy to talk to folks who opt in, and I'll give them ice cream
- 23:53:28 [jamesn]
- q?
- 23:53:30 [aardrian]
- q+
- 23:53:39 [Jamie]
- q+
- 23:54:03 [sarah]
- Matt_King: how does the user -- if I don't want to hear the suggestions, it sounds like you're taking control on the app side, and... One thing I struggle with is if those suggestions are causing more pain, I don't know how to opt out
- 23:54:16 [sarah]
- keithamus: one option is notificationId, you can use that id to censor the announcements or notifications
- 23:54:41 [sarah]
- keithamus: for example, if github had given that an appropriate notificationId, with a screen reader that has the capability, you could silence them
- 23:54:55 [jamesn]
- ack aardrian
- 23:55:01 [jcraig]
- q+
- 23:56:04 [sarah]
- aardrian: some updates came in last week, didn't read them yet, but I have some questions. For notificationId, which happens to be a string, not an id. I thoguht of them as generating ear cons, which is a great feature, which might be me projecting. If that's an option, have you thought about having pre-defined string, like autocomplete, that could
- 23:56:04 [sarah]
- generate pre-decined ear cons. Presumably screen readers could get behind, is that an option?
- 23:56:12 [aardrian]
- q+
- 23:56:29 [CurtBellew]
- present+
- 23:56:40 [sarah]
- keithamus: we've talked about altering it so it's an enumerated list. The issue is where it's specified, and also what happens if I produce one which is not on the pre-defined list. We'd need to somehow specified the list, there's an open question about what that looks lie
- 23:56:53 [sarah]
- keithamus: it could be a github repository, or somewhere else, I'm not favoring github
- 23:57:08 [sarah]
- keithamus: we could use that as a registry to map to ear cons, that's a valid option to explore
- 23:57:30 [sarah]
- smockle: there's a couple open issues around that question. There's a couple open issues and discussion questions, should we go over them or let the discussion flow?
- 23:57:31 [jamesn]
- ack Jamie
- 23:57:47 [jcraig]
- somewhat related to my comment and aardrian's https://github.com/w3c/aria/discussions/1958#discussioncomment-10363453
- 23:58:12 [sarah]
- Jamie: it's interesting because suggestions are a case where I wouldn't use ariaNotify, I'd use aria-control, and [etc]. I'm worried this will cause notifications to get overused, and this is validating that concern
- 23:58:25 [sarah]
- Jamie: is this a valid use case to use it for autocompletes, because I don't think that's a valid use case
- 23:58:39 [jcraig]
- q+ to follow on re notificationId name
- 23:59:06 [sarah]
- keithamus: I think that's a valid concern. I think there are two driving motivations, one is the traditional actual use case for notifications, receiving messages. But we also have a lot of UI in github.com where we use live regions, and this solves those issues right now for us
- 23:59:51 [jamesn]
- ack jcraig
- 23:59:51 [Zakim]
- jcraig, you wanted to follow on re notificationId name
- 23:59:53 [jcraig]
- ack me
- 23:59:54 [sarah]
- Jamie: I think that's the question, where do we think the appropriate use cases are. As we shape the API, ideally we want to shape it around appropriate use cases, and not inappropriate ones. I think suggestions is not an appropriate use case for this. I think it's a good API, but it's interesting that this is defined as a good use case for this
- 23:59:57 [cyns]
- q+