Meeting minutes
[everyone doing introductions]
VY: let’s go over the process review
first topic: monorepo
review: monorepo
one repo for all the specs
all other repos still exist for issues
makes making PRs easier
if you have related issues you can open an issue against the monorepo
the goal is to have things less spread out
review: normative pr checklist
we refined the checklist after monorepo
Github: w3c/
getting closer to “can i use” for aria features
VY: new test for accname
feedback
VY: overall process for landing PRs is long
we’ve made changes over the last couple of years before landing
based on my experience on my experience
it’s nice to know that you’re reading something that’s already being implemented
probably we should review the PR backlog a bit more
any suggestions on that are welcome
specifically normative changes, adding a new feature, etc, maybe we should consider having a champion
having it more explicit would be nice
keithamus: the TC39 staging process is quite thoroughly excercised
it gives a series of gates
quality control
it might be quite a heavy process for ARIA WG
VY: also Mel brouhght this up
<keithamus> s/?? ??/thoroughly excercised process
keithamus: stage one is worthwhile exploring
keithamus: stage two: a draft specification is available for review
keithamus: stage three: is a signal for implementers to start developing the feature
keithamus: stage four: specifications have been reviewed and it is ready to merge into the main specification
it’s good for exploring ideas
not sure if suitable for ARIA
additional guidelines that say that each proposal needs a champion
we can take parts of that process or none of it
there’s precedent there
and if we’re interested in picking that up
VY: we’re not very good at marking when things ahve consensus
we mark it as “waiting for implementation”
but maybe we should tag it as “consensus”
keithamus: there are provisions for implementers
so when it hits stage three, they can move to implementation
this is to prevent them from implementing too early
gives room for prototyping and polyfilling
jcraig:
jcraig: which of those stages includes a call for IP review?
which of those would be the most appropriate to include the legal powers that be
keithamus: every year in may there’s an opt out period
usually that’s met with silence
around that time things get merged into the mainline
<jcraig> s/IT review/IP review/
Matt_King: ?? the process that keith was describing
JN: every two years you take a CR? through the process
Matt_King: with evergreen my question is
<keithamus> s/stage four: ??/stage four: specifications have been reviewed and it is ready to merge into the main specification
when is something in the spec
when would we say something is in the spec?
JN: when you merge the pr
that’s when it’s essentially in the spec
Matt_King: don’t we first merge into main?
and then cut into CR?
Daniel: as soon as you merge to main it publishes
Matt_King: so essentially the editors draft is published to TR
so merging is the decision point?
Daniel: starting by 2025 we’ll be able to do that
spectranaut_: by 2025 we’ll evergreen all specs
aaronlev: just talking about the process
having exact stages
that would be useful
but ?? that there aren’t many people that have time
because busy with jobs etc
so there might be a high burden on people like Scott
i wouldn’t want to commit to it unless i see that it wouldn’t slow is down to a crawl
so evergreen is for all specs including aam?
keithamus: so the tc39 process is an attempt to devolve the editorial burden
the idea of having champion burden the process through
so editors don’t have to do all the heavy lifting
i think that would be the benefit of having champions
aaronlev: is that something we could try ona few issues?
keithamus: i think there are a small handful of proposals
we’re looking how well it fits
it’s more for nascent proposals
spectranaut_: as far as i would think about thinking about this
just having a bit more clarity
when spec changes have consencus of the working group
implementation should inform the specification
i wonder if the staging process can help us
get clarity of where a feature is in the process
Matt_King: i love that idea
just having a PR
and being able to say this is in this stage and being liket his is what that means
JT: if stage three is ready for implementation
if something goes belly up in stage three
and during implementation there’s a major problem
how does that go back to the spec?
like we need to review
keithamus: it’s possible to demote issues to prior stages
we’ve had this with a few issues
with 2.7, we have most of, what you would call a final draft, seeking at least one implementer to implement it
<keithamus> https://
JT: ah so stage three is for all implementers to implement and stage two has one implementer?
keithamus: yea
i linked the process in the IRC so everyone can read it
spectranaut_: six minutes left
any questions about process?
or this particular idea?
smockle: do we have a sense of where our in -flight things are in this process?
spectranaut_: next we’re talking about popover
which is an HTML feature
has mappings in aam
it’s not an aria feature
aria-actions
what stage is that in?
SH: waiting for implementation
JN: do we have an implementation behind a featiure flag?
SH: not yet
<aaronlev> For the next talk on popovers, and for other talks today and tomorrow...
<aaronlev> New web platform feature improvements in HTML and CSS (things that have a significant a11y story):
spectranaut_: let’s do this during the rest of TPAC
state which stage things are in
Matt_King: is there anything in the process that prevents people from implementing?
keithamus: there’s not anything particularly stopping you
but the issue won’t process before the group has consensus
Matt_King: if we did go to a process like this?
would we go to some sort of CFC process?
spectranaut_: might add more bureaucracy
spectranaut_: would be good to have similar stages
Matt_King: could be that the process is different for different issues
new feature should follow this
but editor changes probably don’t
[more introductions happening since new people joined]
popover
<aaronlev> hi
AL: quite a few new HTML features being added
dialog element for example does everything for you... so authors can't make as many mistakes
aaronlev: thanks jocelyntran for compiling this document
a/AL: /aaronlev:/g
aaronlev: run this in a nightly build of chrome
aaronlev: masonf has been working hard on the implementation of popover
diff b/w auto/manual hint type
<aaronlev> <button popovertarget="mypopover">Toggle the popover</button>
<aaronlev> <div id="mypopover" role="..." popover>Popover content</div
popover drawn in top layer, above max z-index
if you open an auto popover and there's an existing one (non nested) it will close any non-ancestor popover
masonf: you can have a stack of nested popovers too
web app can also manage any numbe rof manual popovers
popover handles some kb nav, like focus cycle containment and escape key to close
mk: if it's not next in the DOM, how does tabbing work?
aaronlev: think of the popover tab cycle like a separate tree or branch in the tab cycle
masonf: one example ov manual popovers is that you can have one popover associated with an individual triggering element
scott: can't; e.g. if the trigger is in the middle of a paragraph 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.
aaronlev: popover type and target are separate from the concept of the user action that triggered it.. click/hover
working out how touch etc will work
masonf: discussing this in CSS WG tomorrow too
aaronlev: popover implemented well in all major browsers, needs more work in SRs
keithamus: autofocus attr also affect popover
<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
aaronlev: open issues like out-of-band popovers... e.g. trigger from server timeout
or user getting lost... modal versus non-modal issues.
[discussion of some Windows AT mappings]
<aardrian> JAWS used to offer a command to navigate to targets with aria-controls, is there a similar concept on deck here?
aaronlev: seeking more people to contribute to the open issues
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
aaronlev: "group" is not enough of a minimum role for popover, but we didn't have anything better atm
Matt_King: authors ideally shuold be able to use this without any thought into the popover implementation...
aaronlev: interesting prob, but I don't know the solution.
aaronlev: can't reasonably expect a random author to know about aria-details...
Matt_King: we do expect authors to know that
scott: went over this in some of the deep dives. provide support for the different patterns of popover that show up on the internet.
that's why minimum role is more than generic, but not more specific than group
so many types in the wild that there isnt anything more specific. author can provide a more specific role.
Matt_King: authors could use the APG examples to get something better.
scott: yes and more you don’t necessarily want to expose those if you’re not a sighted mouse user because they’re just annoying scott pls fill in
jcraig: it sound slike aaronlev was saying you can’t expect all authors to know about aria-details etc
you [Matt_king] said something along the lines we do expect people to know that
<Jem> +1 to James Craig
we should prioritise users over authors over user agent implementors (rest of the w3c mantra)
everything written by anyone on the internet, from big websites to someone writing a local blog, have a responsibility to the user
<flackr> +1
it’s the implementors job to make the best user experience regardless of what the author did
<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
<scott> 'automatically'
cyns: accidental accessibility is important... users expect the web to work no matter what the author did.
spectranaut_: slightly different topic... there are mappings for this feature
diffs between that document https://
aaronlev: need to sync that... doc is probably more recent
aaronlev: I don't mind if HTML-AAM lists TBDs
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.
keithamus: speaks to extensible web manifesto.. this is a building block
intent to deliver higher level functionality (menu list for example) using the same underlying popover mechanic
popover could be the primitive mechanic beneath many higher level controls
Matt_King: to the extent we can. avoid breaking well establishing patterns (ex. tabbing out of a non-modal dialog)
we should avoid behaviors that are inconsistent with those user expectations
<Jem> https://
keithamus: are you saying dialog focus trapping that lets you get to the browser navigation bar is a problem?
Matt_King: yes
aaronlev and scott: this has been controversial.
alice: I think rather than non-modal dialogs, Matt was talking about dialogs allowing breaking out into the browser UI
jcraig: thanks alice for the note correction...
<jamesn> cd Jamie /me going to be open format - as we have at folks in the room how can we improve our coordination
<jamesn> s/
<jamesn> cd Jamie /me going to be open format - as we have at folks in the room how can we improve our coordination//
<jamesn> s/
<jamesn> cd Jamie \/me going to be open format - as we have at folks in the room how can we improve our coordination//
<jamesn> cd smockle
Jamie: if we have complete native features like dialog, the hope is that authors will choose that over some custom/partial/primitive... cautiously optimistic
clay: bullet inthe doc: "add details relation" will that be annoying for SR users?
aaronlev: better to give too much info than not enough
SR opportunity for UX innovation
"APG with popover example" was a great idea. who wants to sign up
<cyns> +1
hidde, keithamus signed up to create examples
sarah: rich hovercard examples.... you don’t necessarily want to expose those if you’re not a sighted mouse user because they’re just annoying
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"
<cyns> I smell some test cases
aaronlev: please add those issues to the doc or repo?
Jamie: need to think about real-world use cases, rather than focusing on theoretical ones.
spectranaut_: break time
Process for ARIA working with AT, how can we do better?
jamesn: we’re talking with AT vendors
we have multiple in the room
we want to try and improve the process of working with the APG
without getting AT buy in to actually implement feartures we work on
even if the browser supports them
if they’re not exposed to the user they get lost
one example is aria-errormessage
we didn’t get AT buy in with that
B?: we did support it
but people didn’t use it
jamesn: question? how did you know nobody was using it?
B?: we ran with it being announced on pages
but we didn’t get any feedback
it’s still in our code
the other one that we supported early on were flows from and flows-to
aria-controls was also brought up today
and there’s always been this tension with how early do we support something?
and users need to be requiring
jamesn: should we require AT commitment as part of our process
spectranaut_: I think we should but we don’t at the moment
I collaboration with ATs was too adhoc to make that work
jamesn: some questions we need to think about?
1. should we require commitment from ATs?
2. ?? should we do that?
3. what kind of guidance should we give?
4. (secretly 3) should we @@@?
Matt_King: i will be giving an oveerview of ARIA-AT tomorrow
the net of all that is going to be how we’re making attempts at defining some expectations of some kind for AT
not normative
but testable
that i feel are the kind of things that we can work out in the implementation phase
aligned witht he stage three
i don’t have strong, semi strong, opinions about normative requirements
but more so ??
one thing we definitely learned from this project
is that the there are a lot of details that really matter
in terms of whether or not a feature delivers any value
i don’t think those can all be realistically specced like css for example
looking more to the aams
<Zakim> Jamie, you wanted to discuss clearly documented use cases, why this new thing is better than other options/patterns, AT commitments, AT contacts
they can help us reflect what people are using in real life
Jamie: not an AT anymore, but wearing a semi AT hat
clearly documented usecases for why we want certain things are really helpful
makes it so that at can see why we need it
and also why is it better than something we already have
that should make it easier for AT vendors to commit and get on board
as to the how
i’m not sure
what AT vendors are willing to commit to
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.
i think we could build those relationships with ARIA too
in terms of normative guidance
it’s reasonable to say that ?? should provide information about this element
<aaronlev> Support matrix for aria-errormessage: https://
it’s more about intent than how they do it
hdv: 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
people use aria even if they don’t know if it’s supported well
<Jamie> s/??? should/AT should/
they might now that it exists in the spec
more information about how ARIA is actually implemented would be helpful
jamesn: follow up question based on Matt
should we require someone proposing a new feature writing AT tests if it changes AT behaviour?
Matt_King: that’s too big an ask
i think that would be a community driven thing
<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.
Jemma: when i joined aria a long time ago
i was told we don’t dictate what AT should do
and now we’re talking about what AT…
now we have AT vendors here
wondering if i’m missing something in this discussion
is about the principles
jamesn: originally we got a lot of feedback from AT
telling us they didn’t want us to tell them how to do something
but we now know that they appreciate us speccing how something needs to be exposed
Matt_King: back to where jamie started
it was extremely helpful to have real world examples
showing user value
and business value for at vendors as well
on that specific topic the process that aria-at is following right now and that we’re going to pilot with aria-actions
we have one, thanks to adam, functioning example
we’ll take a look at the experimental features too
in the discussion tomorrow
we’d have multiple
and then from that the aria cg can work with the at vendors on
what are some baseline expectations?
my biggest concern
is characterising it beyond that is testability
at least at this point in time it’s better to have something looser than that
at least until there’s more confidence in the process
and to hdv’s point, knowing support levels/interoperability is the goal of aria-at
<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 more detail
jcraig: jamesn and i were disucssing this in the hallway
if there’s something coming in the spec
we, as in general, tried to object to things that are not implementable or are a bad idea for implementations
but nothing in the spec would fall into that category
like aria-errormessage
another thing to clarify is that it’s a matter of prioritisation
basically everything that’s in the spec all the chain down
it’s just not made it’s way to that prioritisation
<Matt_King> yes
some stuff has a lower priority than existing bugs in implemented features
when aria first started there wasn’t even a plan for testability
it was essentially microdata that was jammed in the html
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
i want to get back around to this idea of testability
to clarify
we’re now at a position where we can reasonably test some things in an automated way in existing and emerging WPT
spectranaut_ will talk about the next step in that (automated platform mappings) later in agenda
the comment about slowing down is that there’s already a lot of ARIA out there that doesn’t work
we don’t want to add another layer of ARIA that doesn’t work in a different way
[laughter]
plus some of the new html features like aaron discussed this morning
that’s kind of the focus of this slowing down
my interpretation is that we should focus on the automated testability
<Jem> James Craig's comments help to answer to some of my questions. - improved automated testing procedures, which are different from the past.
cyns: ??
we’re at a point now where I think we can start to fill that gap
and so yes there’s the don’t box people in and stop them from innovating
but also there needs to be a place to argue
provide feedback
like working in a public group makes it easier for everyone
i think some of the at people agree
aaronlev: as others have mentioned
i don’t think at people don’t want any input
but do appreciate some documentation
the only thing that gets stuff done and get it done well
is when authors start using the new markup
thinking back to css and you get all the bloggers talking about new features
who’s doing that for aria stuff?
we need an authoring community
showing off the new stuff
what i need from at vendors is that want to wait until people are using it
Clay: ?? what kind of setting AT should support?
can we tell AT vendors what we think would work well? in terms of settings?
like aria-notify
we would probably want that setting supported in at?
aaronlev: what i was thinking
i’m not a sr user
people that need to have that conversation should be at users and vendors
<Zakim> Jamie, you wanted to say that things have changed, lessons have been learned
as a browser vendor i don’t want to be too involved
Jamie: there has been a change in terms of what at vendors want to discuss
not having any guidance doesn’t help anyone
i think in the last few years there has been more appetite
<Zakim> Matt_King, you wanted to ask about aria-hotkeys
Matt_King: way back to where, two things, jcraig, i was under the impression that you had comments on aria-keys?
is there anything that we should just not put into the spec?
github: speced/
cyns: we get input from sr users
and we don’t get as much input from other at users
i tried to do user research
i’ve been thinking a lot about how we as a wg could fund some user research
getting real answers about what users want
i don’t know how that funding would work but how can we make that happen?
just an idea that i want to put out there?
<Zakim> jcraig, you wanted to discuss can-i-use? respec vs bikeshed markings and to review this in that context speced/
jcraig: responding to matt about features
i don’t know that i objected to aria-grabbed
<Jem> I think we can have a partnership and collaboration with the disability advocacy group.
jcraig: aria-keyshortcuts i had concerns about
like the french keyboard has some intersting keys
like other keyboards have other limitations
like gmail has different shortcuts for french users
so as long as those keyshortcuts are adjusted to locales it should be fine
[something about an objections]
it’s not that it’s not implemented because of a formal objection
one of the things someone mentioned was this can i use site
effectively showing you if you can use a css feature
it has notes about browser version support etc
can also have notes about accessibility
Github: speced/
one of the ways in which we may consider doing this is an in spec can i use
some note or graphic that shows the support
maybe some automated or periodically manual updating
there’s a lot of AT
we can’t list all of them
but we can have the major screen readers for example
maybe add this to respec?
<Jem> I wonder how this "can I use aria "will be different from AT project.
jamesn: we’re at time
<Jem> so "can I use" is more about 'browser" focused.
maybe we can get some conclusions
it feels like everyone is on board with getting formal or informal buy in from AT vendors
and it seems like everyone is on board with us giving feature guidance, basically how it _could_ be implemented
not normative
Jamie: as long as AT vendors are involved in the process
jamesn: yes
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
StefanS: how will this buy in be communicated?
jamesn: through the github issue is my guess?
spectranaut_: we’ll iterate on that
Jamie: maybe github labels
User agent and authoring requirements for aria-actions
<Jem> https://
Matt_King: in the notes column in the agenda I added this link
Matt_King: I hope these goals aren't too ambitious
Matt_King: the goals are across all aria-actons discussions, we have critical decisions to make re requirements
Matt_King: I spent a fair amount of time after some discussions, APG, Sarah, others have worked on this
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
aria-actions
Matt_King: we need to answer this for all implementations as we don't want differences between the implementations
Jamie: I think the first question has already been answered
Matt_King: great we don't need to set precedent between the two
sarah: the change was made a couple of weeks ago
Jamie: nuance needs to be resolved but will be fine
Jamie: has it been discussed with @@@ ?
sarah: no not yet
jamie: probably won't be a problem
Matt_King: ok let's move to question two
Matt_King: “Must user agents expose aria-actions in the order the IDs are specified by the author?”
Matt_King: I believe we want to make sure authors can control the order of actions
Matt_King: my proposal is that we add a normative UA req regarding this
sarah: I agree, I had intended for the order to respect the order of ids
sarah: unless anyone has concerns re the implementation of that
sarah: unless it's better in AAM
Matt_King: I think in other places, where we do it, we have it in ARIA
Jamie: and would be tedious to describe for every AT, as people who read AAM might not read the right section of ARIA
jamesn: we want authors to know as well, they won't read the AAM
Matt_King: let's talk about the third question: “To which descendants must user agents propagate aria-actions?”
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
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?
<Zakim> jamesn, you wanted to ask what the use case is for inherited actions
jamesn: what's the use case for inherited actions?
Matt_King: there is one cited in the definition: closing a dialog from some place inside of the dialog
Matt_King: I don't particularly like that one
<Zakim> jcraig, you wanted to respond to "inherited actions"
jamesn: do we need it or can we make it so that we don't need inherited actions?
jcraig: I can speak to that… one of the examples is closing a dialog
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
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?
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
jcraig: one of the way it could work is if there is an action with the same name, we keep the local one
jcraig: so when they both have a delete action we keep the delete action localy and not the inherited one
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
Jamie: close dialog is an interesting case, but not a match for aria-actions in a lot of times
Jamie: there was discussion in AOM I think re when ATs trigger that action, synthesize an Esc key event
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
Jamie: one final comment… the spec currently requires something is focusable in order to have actions, which brings the dialog into questions
sarah: yes… maybe we can make that more explicit
sarah: I agree … I don't think actions should be inherited, if there was a use case authors could do that
sarah: I think we wanted to have an example of a container type widget with associated actions
sarah: maybe video player
jcraig: the play/pause button, in theory the play button on my keyboard should trigger the same
jcraig: video player is a reasonable example
cyns: much easier to add it later
Jamie: agreed
Matt_King: if we're taking away inheritance, what about the video player example? Re the question of focusability
Matt_King: most of the things are not focusable, so there is no focusability requirement now
<Zakim> Adam_Page, you wanted to give example for aria-actions on container
Matt_King: if we take away inheritability we probably need to restrict aria actions to specific elements
Adam_Page: another use case for aria actions on a container: a scrolling code block where you can copy the contents of it
Matt_King: how do you do that without inheritance? then you could only access it when focusing the contianer
sarah: yes
Adam_Page: yes that was my intention
Adam_Page: in this example if makes sense to have the action on the container
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
<Zakim> jcraig, you wanted to discuss focusability and to talk about the click implementation
Matt_King: are we all good on that?
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
jcraig: this isn't ARIA specific, CSS and HTML leak this all the time
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
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
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
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
jcraig: the element with the aria actions attribute on it does have to be focusable
<Zakim> Jamie, you wanted to clarify "most of the things are not focusable"
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
Jamie: re the leave node question: is the concern with that the cell is focusable?
jcraig: first cell have a checkbox in it
Jamie: does that need the actions? not sure how that is a problem?
jcraig: just because I am on the checkbox I don't want to be able to delete or move the message?
Jamie: you've decided to go deeper at that point
Jamie: if you focus the row, which is what you normally do, you get the acttions…
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
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
jcraig: agree with that
jcraig: I think implementation would probably work as you described it
Jamie: just wanted to flag that flattening is not the only way
sarah: I just added the open question, “should screenreaders sometimes expose actions” to my doc
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
sarah: there are too many contextual things, it depends on the context what level of inheritance is most useful
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
StefanS: I think this discussion would be more helpful if we start with a simple example and then go to more complex one
StefanS: more concrete examples should help here
StefanS: and define what the best practice for it would be
<Zakim> smockle, you wanted to ask about aria-activedescendent
smockle: could aria-activedescendant containers in trees have actions ?
<Zakim> Matt_King, you wanted to ask about interop of if AT walk up tree
Matt_King: StefanS, we are going to talk about AT expectations … we do have a simple example in the APG
Matt_King: there are references in the top of the doc to go to the APG
<Jem> https://
<Jem> APG example - Tab actions by Adam Page
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
Jamie: oh yes I think it should be explicit
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
sarah: everything except elements that cannot be named… eg nameable elements
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
Matt_King: we don't want to encourage people to make regions focusable so people can have actions on them
sarah: I think the question is encouraging vs limiting
sarah: eg I wouldn't tell people to make an article focusable
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
Matt_King: right now there isn't anything in prose that says @@@
New CSS Features
Session: New CSS Features
https://
Question: Are we discussing ‘where to map’ CSS stuff today?
aaronlev: No, not today.
aaronlev: Right now, it’ll go in html-aam.
aaronlev: We’ll start with CSS Anchor Positioning. Jocelyn is very close to landing this in Chromium.
aaronlev: In the discussion on GitHub, people prefer a 1:1 relationship between the elements.
aaronlev: The relationship will be similar to `aria-details`: starting with the anchor, pointing to the thing anchored to it
sarah: Are there any role restrictions?
aaronlev: Should we restrict when we do the automatic aria-details relationship?
aaronlev: `aria-details` can go on anything, so I’m not sure this should have any additional restrictions
aaronlev: Anything with `aria-` causes an element to be exposed in the Accessibility Tree.
Matt_King: Do the APIs have a way to tell AT why the relationship exists?
aaronlev: We’re planning details-from for that.
Jamie: Real-world use cases is something we need to talk about more.
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).
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.
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.
<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 attribute `aria-detailsfrom`
jamesn: I’m concerned this will lead to a proliferation of details, another instance of the `aria-controls` problem where it gets turned off.
aaronlev: We will provide an additional hint to ATs
aaronlev: We’ll expose all the information we have, then ATs can make the best decision for their users.
aaronlev: Skipping to ::scroll-marker
Deep link to ::scroll-marker: https://
flackr: :scroll-marker and scrolltarget creates a table of contents for your scroll, to support e.g. making a carousel.
flackr: A group of navigation links, it should expose how many there are. You should be able to give a descriptive name.
<Zakim> jamesn, you wanted to ask is there a demo available?
flackr: `scrollButton(direction)` lets you set up “next” and “previous” buttons for scrolling a carousel in a specific direction
<Jem> https://
<Jem> https://
flackr: These APIs were designed to follow these demos.
aardrian: What was decorative?
flackr: “decorative” was the wrong word; it is functional.
<cyns> Examples from w3c/
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?
<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.
<cyns> https://
flackr: The author of the site styles the scroller with a scroll marker group, containing `::scrollmarker` ← this pseudoelement is the control.
<cyns> https://
Matt_King: How can you specify the semantic role of that scrollmarker?
flackr: You cannot give a role to a pseudoelement; it’ll have one by default: button.
Matt_King: But shouldn’t they have the tab role?
<Zakim> jcraig, you wanted to reask my prior question about focusgroup,
Jamie: The scroller could have a role, and we could infer the scroll marker’s role from it
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?
flackr: The scroll marker group is implicitly a focus group.
jcraig: How would you define—when you scroll to this group—where keyboard/screen reader focus is supposed to land?
<cyns> Can someone who is in Zoom present this https://
flackr: If you click e.g. the 3rd scroll marker, focus will remain on the marker.
<Jem> https://
jcraig: Can this widget be gamed to be something other than a scrollmarker?
jcraig: Not gaming the role, but repurposing the scroll marker concept to get some jumpy UI on the screen?
jcraig: e.g. a selection widget or form element
sarah: Like if you needed an element to trigger focus mode
jcraig: Radio button jumps to mind
flackr: I suppose there are examples where people use a carousel as a selection mechanism (e.g. levels in a game, Mario Kart tracks).
<Zakim> Jamie, you wanted to note that setting next focusable element doesn't cover the screen reader UX
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.
flackr: It is similar to fragment navigation, which is in the HTML spec.
Jamie: We need to make sure this gets mapped equivalently
<Zakim> sarah, you wanted to react to sarah
sarah: If you query `document.activeElement` when one of the scroll marker pseudoelement is focused, what do you get back?
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.
sarah: How can you programmatically focus one of those?
flackr: You cannot.
<ZoeBijl> +1 to sarah’s question
sarah: Is there a reason to do this with pseudoelements?
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.
flackr: Pseudoelements is the only way to support the dynamic pagination use case.
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?
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.
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.
cyns: Are the next and previous buttons pseudoelements?
cyns: Where should next and previous buttons be placed? There is inconsistency among demos.
<Zakim> ZoeBijl, you wanted to ask why is it the only way to support dynamic pagination?
cyns: My gut would be to put them together in the accessibility tree.
ZoeBijl: Why would dynamic content require pseudoelements?
flackr: This doesn’t require JS.
<cyns> should psuedoelements for previous/next buttons be together in focus order, even when they are visually before and after the content?
aaronlev: Moving to CSS reading order; `reading-flow`
aaronlev: You put this attribute on a container, then all elements will be re-ordered. Example values: `normal`, `flex-visual`.
aaronlev: Only DOM siblings are reordered.
aaronlev: It reorders the accessibility tree to match the visual order, similar to `aria-owns`.
aardrian: Which takes priority: ARIA or CSS?
aaronlev: ARIA.
aardrian: `display: contents` is still an outlier because it blows away the box.
aardrian: I saw all the values this has—does this support absolute positioning and floats?
aaronlev: No, not currently.
Jamie: There is an implementability concern for us
Rahim: What is the relationship between `reading-flow` and `order`
Rahim: The `order` spec says it’s not to be used for anything beyond visual ordering.
`order` changes visual order of flex children; `reading-flow: <something>` gives the accessibility tree the ability to match that
cyns: Isn’t `float` usually siblings? Couldn’t `reading-flow` work with `float`?
<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!
aaronlev: `float` is usually legacy; I don’t think we should do anything about `float`
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?
<aardrian> aardrian
aaronlev: DOM siblings can be reordered relative to each other.
<Zakim> Jamie, you wanted to ask where the non-DOM siblings go
aardrian: I gave feedback: Let’s not do this in tables.
jcraig: This doc says that anything out-of-view is `inert`. That seems wrong.
flackr: “outside of the particular scroll port” is better wording than “out-of-view”. Document updated.
RRSAgent: make minutes
Interface Definition Language (IDL)
[quick five minutes break]
Rahim: good afternoon
talking about aria from the html markup
getting this right is important
for a number of reasons
aria should be easy to use
thinking about accessibility in general
this complex topic requires doing a bunch of groundwork
so we’ll have a somewhat longer introduction
at the half way mark we’ll pause for questions
the story starts with idl in general
[example of a button]
code has a html button and some javascript setting and requesting attributes
web interface definition language (idl) describes web APIs and their methords and properties
browsers implement these so they’re interoperable
for our button element it inherits from our buttons element
similarly for the type property
this is also a string
it’s found in the IDL type definition?
you might notice I’m using the “type” attribute property
IDL and content attributes aren’t the same
they’re two things that are represented by one thing
highlighting some of the differences
??
while IDL attributes are used to programmaticallt interact with the DOM and its nodes
we use them as accessors directly
importantly
content attributes aren’t simply text
for example the disabled idl attribute is true or false
the content attribute is a string equal to these values
content attributes are string based
To summarize, content attributes are what is in the HTML markup
They are string-based, are serialized as part of an HTML document and sent over the wire
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.
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
Although they’re different representation of a singular thing, It makes sense to keep content and IDL attribute values synchronized
More formally, spec often states that an IDL attribute reflects its content attribute
[showing some examples]
the example is updating a input element’s id
showing that now getting this attribute shows the updated value
another example shows updating the type attribute via setAttribute
in this example we’re doing the same but the value is being set to “foo”, an invalid value
getAttribute("type") will default to text
what if there’s no [type] content attribute on the element?
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’
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
In short, attribute validation is one of the things we get from IDL among other benefits which we’ll discuss shortly
The “foo” IDL attribute doesn’t magically show up in the HTML markup as a content attribute
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
regarding reflection in html do different things
- Some are true/false like disabled or inert attributes
- Some attributes are enumerated, i.e., they have a set of permissible values. For example, the ‘type’ attribute for <input>
- Some attributes are simply strings, such as “id”
- Some attributes are numeric, such as colspan and rowspan, and so on and so forth
The takeaway here is that content attributes can be categorized into types, and IDL attributes definitely have their own types as well
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
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
classList represents space-separated tokens but implemented as DOMTokenList and colspan represents a non-negative integer but implemented as unsigned long
For the purposes of reflection, the content attribute type and IDL attribute type are both important
Let’s take a look at all of the content attributes in the previous slide and see reflection works for each of them
The ‘title’ content attribute has no value constraint, and its IDL attribute type is DOMString
When the 'title' content attribute is missing, it reflects as the empty string
When the content attribute is set to the empty string, it reflects as the same
And when the content attribute is set to a value such as “a large button”, it reflects “a large button” for the IDL attribute
The ‘disabled’ content attribute is a boolean, and its IDL attribute type is also boolean
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”
If it’s missing, the content attribute returns null and the IDL attribute value is false
We saw in previous slides how the ‘type’ attribute for <input> elements reflect
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.
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.
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
ariaActiveDescendantElement is the only ARIA IDL attribute that reflects as nullable Element
which means that when the attribute is missing or set to the empty string, it returns null
And when the content attribute is set to a valid ‘id’, it returns an element node reference
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”
that’s what the spec means by nullable
it means that it supports this “null” value
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
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
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”
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
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
when a developer tries to set a null value to a non-nullable attribute
IDL will delete the attribute?
Non-nullable DOMString reflection such as id or title take any value and simply returns it or the empty string
a couple of other examples
classList represents space-separated tokens and IDL type is DOMTokenList
When the content attribute contains one or more classes, it reflects this as a DOMTokenList
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
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
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
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)
So, that’s an overview of common reflection models for some HTML attributes
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
I definitely bears noting that reflection is well-defined in HTML spec and other languages should lean on it where possible which includes ARIA
Alright, my presentation is called ARIA IDL and we haven’t even talked about it yet!
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
here’s a screenshot of an ARIA IDL definition block
Rahim's slides are here, by the way: https://
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
And importantly, currently, every single ARIA attribute reflects as one of three types:
- Nullable Element
- Nullable FrozenArray<E> (which takes an element)
- Nullable DOMString
Let’s walk through the reflection model for each
ariaActiveDescendantElement is the only ARIA IDL attribute that reflects as nullable Element
And when the content attribute is set to a valid ‘id’, it returns an element node reference
All of the ARIA attributes which take a set of IDRefs such as ariaDescribedByElements, ariaLabelledbyElements, reflect as nullable FrozenArray<E>
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
And thirdly, and most importantly, the overwhelming majority of ARIA attributes reflect as nullable DOMString
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
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
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.
However, ARIA attributes are not enumerated
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?
However, there are a number of very good reasons why ARIA uses and in fact requires nullable DOMString?
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
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
And since we can’t do role-specific reflection with the HTML reflection model, nullable DOMString seems like the next best thing
Nullable DOMString reflection additionally means that a11y APIs can handle complex validation downstream since the browser is not performing any further validation
either it’s null or the string value
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
there are strong reasons for nullable DOMString reflection, it does introduce several challenges that may not make it the most optimal solution long-term
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
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
Another challenge is that ARIA isn’t currently able to take advantage of robust feature detection
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”
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
There’s also ambiguity around why numeric ARIA attributes such as aria-valuemin/valuemax reflect as strings
as a devleoper
you might intuitive think they’re numbers
but they are strings
at present
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?
it creates a divergence ??
a future where we want to have a numeric type
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.
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
These proposals are roughly ranked from worst to best, or perhaps least desirable/tenable to most
there’s about six of them
The first proposed solution involves removing role-specific default values on a per-attribute basis
For this proposal, attributes like aria-orientation, aria-selected and aria-pressed could always default to “undefined” regardless of the element’s role
Benefit of doing that we’re going to align with the HTML spec pretty well
We would have our missing attribute default
it would also simplify some of the validation
the draw back
it doesn’t necesarily align with ??
it’s unclear how this impacts the user experience
the spec currently says that ??
this one definitely is probably a non starter
For the second proposal, the ARIA spec could align with HTML reflection with role-specific IDL
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
Here’s a high-level view of how that could work
it could be defined as an enumerated attribute with IDL type of nullable DOMString
We could have multiple keywords that map to a a single state
the missing value default could be called auto
This proposals is definitely more easily said than done
the benefits are pretty clear
easier inter?? between aria and html
we would definitely align closer with HTML reflection
it would be relatively simple to continue using a similar model
the main drawback
that jcraig educated me on
implementing role specific ideal would require execution of accessibility runtime code
perhaps it could result in some sort of circular refence
jcraig: it could result in major rewrites in browsers
Rahim: other drawbacks
??
???
at the browser level
webkit aria-orientation detects ??
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
A good example of this is aria-modal which could be converted easily to an enumerated attribute
Note that aria-modal has no default value which makes it relatively easy to align with enumerated, nullable DOMString? Reflection
missing value default would be false
invalid value default would also be false
some attributes will require default values that are role specific
another benefit all aria idl attributes could have standard processing model
which would simplify specs
the drawbacks are that we have role specific needs for idl reflections
For proposal #4, the ARIA WG could await formalization of reflection in another spec (such as HTML).
there’s work that’s taking place, AnneVK, Domenic
it would take into account ARIA’s needs
<ZoeBijl> s/Anna/Anne/
HTML spec could be the place where all of this is specified and quantified?
propsal #5 we could keep what we have
For proposal #5, ARIA could keep string reflection as is and new IDL attributes for some attributes
A great example of this would be the class content attribute which actually has two corresponding IDL attributes
this is already done in HTML
if i want to add class i would have to concat the value
and removing it would require string manipulation
classlist already solves this
a benefit is allows ARIA to keep current string-reflected attributes as is
like aria-valuemin could have a new IDL attribute
like ariaMinValueNumber
New attributes will benefit from HTML-style IDL (e.g., enumerated, numeric)
drawbacks
May introduce confusion on ARIA JS usage since multiple IDL attributes can map to a single content attribute
May complicate implementations
And finally, proposal #6, ARIA could keep string reflection exactly as is without making any change
benefits are that it currently works
requires minimal work
allows for role-specific validation to occur downstream at AT layer
drawbacks
May not be ideal to have fully customized reflection for ARIA from IDL purist perspective
Doesn’t fully resolve undefined confusion
Confusion on IDL treatment for new ARIA attributes
[aria-notify session will start ten minutes late]
keithamus: i had a question around the implementation difficulty of computed reflections
are we saying this is not tennable?
because of the disconnect of the aria attributes and IDL?
could we get a lazy getter?
struggling with the implementation difficulty side?
jcraig: role computation in most accessibility runtime is done in the accessibility code
browsers are tuned to be as fast as possible
what this takes is to carve out all places where we’re computing these roles
and take it out of the accessibility runtime
there’s a lot of risk
Jamie: it’s not only aria roles but also implicit role
that can impact how the defaults can be computed
jcraig: there’s heuristics to be considered too
it’s a huge amount of work
it’s possible
but there’s a risk
keithamus: another thing to clarify is that we don’t have to map missing and invalid attributes
they’re optional to ?? attributes
we could do this in smaller steps
where we could say go through all the domstring? idl
map the missing ?? to all ??
so filling the gaps
jcraig: yea for all the enumerated attributes it could be possible to continue that way
keithamus: it sounds like folks aren’t sure on the value add
<Jem> This is the discussion of paradigm shift.
the reflection is a very important education tool
it helps, it’s a run time validation, you can see what ?? by just noodling in the accessibility inspector
to validate your web application, which relies on computed values, is important for weba pps to test their ??
Rahim: ?? that’s not formalised in the HTML spec
so yes it could be that there might be a day where you can simply ?? as a nullable domstring
it doesn’t circumvent the issue of calculating a ??
in my mind i think that having the ability to know what the role is
makes what aria ?? so difficult
cyns: a lot of great inormation
thanks for explaining
what i didn’t get is what the problem is that we’re trying to solve
is it just html or does it face users?
Rahim: the number one challenge there is this alignment with how ARIA currently reflects
when Anne and I discussed it we called it a bug
from an IDL purist persepctive aria is doing something different from what the html spec allows
using attributes from the authors perspective ??
but aria-modal is a string? why? it’s confusing to authors
the number one benefit is to have developers have a much simpler understanding of aria
use it in a simpler and easy to understand way
cyns: so the issue is that it doesn’t match html?
jcraig: no
there are implementer benefits
like copying stuff from idl
keithamus: like code generation?
jcraig: yea
which would be more reliable if we write this implementation
one of the things we can agree on here is that there are ??
because we have these things in the spec before html did it
<Zakim> jcraig, you wanted to react to cyns to respond to cyns ?
before we had idl at all
maybe we can agree to not break these patterns in the future
cyns: ????
keithamus: add our own reflection rule
the same but different
which is used exclusively for aria properties
cyns: our perhaps html didn’t consider all the use cases
jcraig: it doesn’t ?? but it does ??
cyns: what’s html stopping from doing that
jcraig: being able to add a IDL attr by role rather than by element type give us the most benefit in the long term but I can't speak to how complex that implementation would be in IDL
cyns: that helps
but i still don’t quite understand the issue at play here
Rahim: with svg
i’m not sure ??
i think there’s some nuance here
Matt_King: i love all the pro’s and con’s
there were a few downsides to number 5
min number and max number
could there be a 5.1?
where you can get past that developer confusion?
Rahim: great question
keithamus: there’s precedence for that
there’s idls for input value
because input has different types
value as number will parse it differently from value as string
we could do the same thing here
i dislike it personally
it aids to developer confusion rather than fix it
Jamie: are we proposing changing the existing IDL attributes?
browsers are all shipping
but I don’t think we can change the existing idl attributes without breaking the web
Rahim: i don’t think we need to change the attribute types
it wouldn’t involve underlying attribute types
Jamie: as soon as we change ?? we need to change the underlying once
jcraig: yea even just the enumerated ones
Jamie: we could support token ??
jcraig: ???
Jamie: it could be that html exposes semantics that we don’t know about here
sometimes html specifies semantics that aren’t defined in aria?
unless the accessibility layer is running we don’t know those things
jcraig: html always wins
Jamie: aria-disabled
if we said the default for that is false
????
jcraig: aria-disabled is a @@@
we never defer to aria in that particular case
if button doesn’t have disabled but does have aria-disabled it’s not disabled?
<Zakim> Jamie, you wanted to ask: can we do any of these things without backwards compatibility breakage?
Jem: i like the idea
it would be good if things were easier
but if there’s only one thing we can work on
which would it be from your proposals
Rahim: it would be converting all the enumerated attributes that do not have a role-specific default defined somewhere
that way we get defaults, validation, feature detection
jcraig: all of the enumerated attributes that do not have a default specified somewhere
cyns: was it one of your numbered options
Rahim: it’s on slide #77
jcraig: there’s a few things we can do further down the line
maybe we don’t want role specific defaults?
?? in addition to the string
we can decide those individually
Rahim: will work on PR
hoping to get that reviewed
<Jem> https://
RRSAgent: make minutes