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+