Meeting minutes
hi Zakim
[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
ariaNotify
<alisonmaher> https://
alisonmaher: the document has a summary of (everything)
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
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
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
alisonmaher: github has some demos to share
keithamus: we've been developing a polyfill [echo echo]
keithamus: demo'ing NVDA on an example page
keithamus: let's actually demo this thing
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
keithamus: we have some new ideas around user experience that don't fall into the existing features of HTML
keithamus: [demo'ing typing text into a textbox that shows a ghost autofill]
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
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
keithamus: it's helpful for us developing the polyfill, but it's also helpful this session
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
keithamus: I'm happy to talk to folks who opt in, and I'll give them ice cream
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
keithamus: one option is notificationId, you can use that id to censor the announcements or notifications
keithamus: for example, if github had given that an appropriate notificationId, with a screen reader that has the capability, you could silence them
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
generate pre-decined ear cons. Presumably screen readers could get behind, is that an option?
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
keithamus: it could be a github repository, or somewhere else, I'm not favoring github
keithamus: we could use that as a registry to map to ear cons, that's a valid option to explore
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?
<jcraig> somewhat related to my comment and aardrian's https://
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
Jamie: is this a valid use case to use it for autocompletes, because I don't think that's a valid use case
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
<Zakim> jcraig, you wanted to follow on re notificationId name
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
<jcraig> https://
jcraig: I think this is somewhat related to adrian's comment and matt's. THe link is some questions that I asked, mainly around the topic of how do we keep this one from being annoying too. I'm positive on this, I think we can get there, but there are so many accidental misuse that I think is the more common case. Like putting role=alert on a
timer, which leads to things like VO users turning off live regions altogether across the entire web
jcraig: there are some use cases like shutting this off on a per-site or per-domain basis
jcraig: this is going to sound like a nitpick, but I think notificationId is the wrong name for it, because it sounds like it needs to be a unique id. But it needs to be a type or a class.
Jamie: for what it's worth, everyone in the last meeting agreed that we should change the name
alisonmaher: I have an issue open to change it to type, we can change it to that
keithamus: I think type is important, because in github regions have surprising semantics sometimes. For this, you call the method for a given string, and that's easy to spot in code review
jcraig: I agree, this is much improved over that
aardrian: priority and interrupt, to set the stage, I've worked with devs over the past years that are painful to recount. They don't understand the difference between polite and assertive. Priority and interrupt are two axes. Doug provided a matrix that's helpful, but my gut tells me that I won't be able to explain it to devs
aardrian: from the matrix, priority important won't override priority none, I want to check that I'm not misreading that
alisonmaher: yup, and there's an open issue
alisonmaher: I'm happy to go through the proposal, the update is for high pri items to flush out both high pri and low pri notifications of the same node. And then any low pri would still just only flush other low pri. So that's my proposal for update, to make that much better for what authors want to be using for, I think
Matt_King: since the API is imperative, what if flushing was just a separate method. Like, you just, if the author just said "I want to flush stuff out" rather than buliding it into those props
jamesn: because they wouldn't
Matt_King: if the option to do it is there, but you were arguing they might not set priority and interrupt correctly. What's the difference between not setting interrupt and having a separate call to flush it?
<Zakim> Jamie, you wanted to flag AT implementability concerns about interrupt and priority taking the source node into account
Doug: are you flushing it because you want to stop speech, or because you want to speak the new string. And if you want to speak the new string, it makes sense to do it all in one
Jamie: I have real concerns about the, right now interrupt takes the node into account. Every node effectively ahs to be considered separately. I don't know what it is for JAWS, but for NVDA it's going to be extremely hard to implement. I mean like a ridiculous refactor
Jamie: and I'm looking at the mac API, and it has priority but not [?]. I'm worried about implementability for this
Doug: I talked to folks on this, and he said it was possible, but there might be performance issues for this
Jamie: I'm not saying it's impossible, but I'm talking about difficulty, and it might take 5 years to implement. I'm wondering if it should be part of the initial spec if it'll take forever to implement
Matt_King: could someone explain the node part?
Jamie: [explains it]
Jamie: right now, NVDA cannot reorder based on the source node, and that would be a significant factor. I know narrator can do this, but it might be the only one
jamesn: we were discussing, or someone was discussing notificationId, badly named, whatever. Have we thought about using microformats like the rel attribute does? So it's not formal like a spec, but people can put their values that they use?
<Zakim> jcraig, you wanted to discuss verbosity prefs, sound icons, etc.
keithamus: I think it would be something along those lines
jcraig: I put myself on the queue to discuss verbosity prefs. I suggested that in addition to the type, that there'd be a keyword list for different types of things?
aardrian: I suggested a keyword list?
jcraig: I think that's this, iCloud is one of those places that use one of these live regions. One of the things you couldn't check is what the user's preferences were. So if you're going through and hit a link, you don't know if the user wants the sound ear con
jcraig: It could be a platform specific things instead of using the web audio api. But in addition to that, jamie's question about how the notification api works
jcraig: if you have a different view open, it's not going to be chattering at you when you're in a different tab. Something I haven't understood,
Jamie: [something i missed]
Jamie: if I queue a hi pri message from node A, a low pri message from node B, and a high pri from Node C, how do those get ordered
Jamie: right now NVDA can't do queues per node. It's not impossible, but not implemented
smockle: I don't think node-specific priority is part of this. Clearing is, but there is a global priority, at least that's how the polyfill works
Jamie: is node-specific interrupt a thing?
smockle: yes
Jamie: so that's the same thing
aardrian: one of the frustrations I hear from SR users nowadays is that if they miss a live region announcement they mis the content and can't review
aardrian: once we get into the more complex matrix, since text can be clipped instead of flushed, I'm worried that users can't go back and check, Doug said this is something SRs could offer to users, my suggestion is to find a way to say dear screen reader authors, can you make a cache more readily available to back through messages you may have
missed
aardrian: I don't know if that's at all compelling or if it shouldn't be specified and left up to others
<Zakim> smockle, you wanted to discuss how nodes are used
keithamus: no strong opinions, seems reasonable
smockle: so renaming notificaitonId to type, have high-pri interrupt low-pri, those are things we have consensus on. Jamie, you suggested dropping interrupt
smockle: are there thigns we can do to interrupt besides dropping it to get it out, could we have it not tied to a specific node?
Jamie: yes
Jamie: everyone acknowledges that this is important, and I want to raise this so this doesn't become a thing that prevents it from being implemented. So I want to remove as many of these blockers as possible
Jamie: that is one proposal, I think we should talk about it more
Doug: I think we're still talking about an assertive queue and a polite queue, I think. And today, if an assertive comes in, it will interrupt everything. I don't think it'll interrupt another assertive, but it'll interrupt everything else
Doug: also if a keypress comes in, it'll flush everything. So I think we can make this better by giving better guidance to SRs to not interrupt assertive on keypress, so we're not interrupting anything, we're just setting the prioirty of those strings to come in front of
Doug: using Narrator as an example, if an assertive comes in, it goes to the front of the queue but doesn't interrupt anything. Techniques like that will help the biggest complaint users have, where they were missing information. I think this will help get less of that experience. I still like the idea of speech history, but I think this will help
Brett-Lewis: I just want to re-emphasize what adrian was saying earlier that users need history for these announcements. And being able to categorize them, filter, have sounds play. I think your point that it can be hard for users to find these features, we have a whole notification manager and I don't think it's used all that much for exactly that
problem. It's hard to figure out and hard to use. I don't know if it's the role of the ariaNotify spec authors to come up with how for users to do that, I think a lot of people who have opinions, but I think we need alternatives in SRs rather than a spec for how to do this
<Zakim> jcraig, you wanted to respond to aardrian's question about missed notifications log
keithamus: this should allow for an oportunity to have a better contract
jcraig: earlier Adrian asked about the notifications log, if a lot of notifications come in and they get cleared, otherwise you can have seconds or minutes of data, so clearing a queue has obvious use cases. But in the context of a missed notifications log, every time I've heard this proposed it's been suggested that the SR should manage the log,
have enough understanding from the API. I don't know if that's a reasonable expectation for the SR to maintain a history of notifications from the app that it has no context for or knowledge of
jcraig: maybe this is something that web app manages, that the SR has access to
jcraig: what would the SR do in the context that the user wants to go back to one of the notifications and click on it, should the web app get an event at that point? That goes agains some of the principles
aardrian: I agree it's a bit hand-wavy, maybe web authors should flag notifications that should be able to be gone back to, I think that's not a good idea on its face
Matt_King: another potential wild idea here, I know for sure I"ve experienced this, I'm trying to remember where, maybe iOS. The problem of speech getting interrupted by timing is solveable on the SR side if SRs decided to do multiple channels of speech. I hear snickers [from Brett]
<aardrian> i snickered too, but for the wrong reason
Matt_King: you could have a notification voice that is separately interruptable, so if you're typing you can hear the notifications coming from chat. It's pretty awesome that you can keep on typing but you can still hear the full notification and respond instantly. I know there's design problems, but I think we should think about that
jcraig: so your use case is not multiple notifications from the same web app, you want the full notification queue runnign while you have the echo?
Matt_King: you still have the whole queue that come through from the API, but you have a separate speech. Or if something comes in and there's something else going on, I could interrupt that and hear the notification
Matt_King: two different interrupt keys, one for notification speech and one for normal speech
Matt_King: it's a thought, it works really well in message where I've experienced it
jcraig: looking at my right control key
[laughs]
Daniel: you could put a setting in
Matt_King: I want to know if anyone else has experienced this, the key is to give the user the ability to manually interrupt those self-voicing notifications
Matt_King: you could even split them left/right ear for folks who can take advantage of that
Daniel: there are some implementations of braille that could use that
jamesn: while that seems like a great thought and possibility, I think it would be a user choice
Matt_King: it could be a great default choice
jamesn: it could be a default, but they should be able to disable it, and have regular queue and interrupt
<aardrian> This feels like a power-user choice, based on experience with clients, community.
Jamie: I'd be wary of any pattern that ties to any one pattern for output. We could have multiple voices, but here's an example: if I'm reading speech at 900 words per minute, I can't process two channels of speech
Jamie: there's already enough gnashing of teeth over the steep learning curve for SR users as-is, we can't do things that make it even steeper. Designing the entire experience around one solution like that is risky to me
Matt_King: I wasn't saying design the experience around it, how do you make it possibel for users to continue to interact with their computer while they're receiving notifications. Now i have to stop to listen to a new message come in. Since I don't have to have keyboard echo to listen to a response, and I don't know when a response is coming. So
the notification is coming but I'm typing, so I never get to hear the new message coming in because I can't stop my typing in time to hear it, so I miss every notification coming in so I have manually go back and review it
Jamie: for some people, that might be preferred
jamesn: Brett's on the queue to solve all these problems
Brett-Lewis: I was one of the people who snickered when yous aid that Matt, I was one of the people who was in a call in 2014 when you proposed that same thign
Brett-Lewis: I was going to say though, I think we want to make sure the API supports the kinds of things Matt's talking about, but I think that's beyond the scope of what matters here
aaronlev: nice try
Matt_King: I'll build a screen reader when I win the lotto
Doug: there's nothing stopping a SR from implementing it
Brett-Lewis: yeah, you can even do split braille. Also Matt, braille would be your solution fo ra. lot of this stuff, right?
Matt_King: not likely
keithamus: as wonderful as that convo was, I'd love to go back to the issue list
jamesn: you have 10min
keithamus: 10 minutes, great
keithamus: how do we resolve this for IA2, the current API relies on UIA
aardrian: I thought that NVDA had committed by reading both, based on a comment I saw?
Jamie: more or less the same thing, I don't see any benefit to having an IA2-specific way to do it, both from the browser side and the SR side
Jamie: it makes it harder rather than easier
sarah: I originally brought that up mostly to make sure that this was considering other platforms, not just IA2
Jamie: agree entirely, just not for IA2
alisonmaher: it is very UIA-based, I'm not aware for any support outside for this
Jamie: mac and android
<Jem> +1 jamie teh
jcraig: we are open to changing APIs, if there's compelling need. There is some support for interrupt, but I don't know if every aspect of interrupt is supported
keithamus: the isssues are how does the interrupt prop work, I don't know if we've settled that
jamesn: we've settled it needs to change
Doug: I wonder if you get rid of interrupt, and go with priority, is that enough?
Doug: I think all platforms support a priority approach, I jsut hate to see this whole thing bogged down with this at this point. Is it important enough to bog it down or not
alisonmaher: I guess the question is would authors find enoguh value in this over live regions?
keithamus: there's certainly still value. I think interrupt is a nice feature, but the other features inherent in the design are more valuable
smockle: one of the problems we came in with was coordination between multiple components on the page all sending live regions. And we started having longer and longer delays. I think our issue is less a single component needing to interrupt itself, and more lots of components needing to not interrupt eachother
keithamus: maybe another API method that could effectively just cancel whatever is currently being announced. Maybe moving that option out of the API
smockle: or maybe cancelling for a given node or a specific type, is more flexible
<Zakim> jcraig, you wanted to mention some fingerprinting missteps with the web speech API
jcraig: I haven't seen anything in ariaNotify that leads me to be concerned, but I think maybe it'd be good to point out past issues that lead to fingerprinting
jcraig: there was a web speech API that wes reasonably well supported, and it goes to everyone regardless of having a SR running or not, so you could make a self-voicing application. But with email there were people that took advantage of that to query what voices do you have on your system, but at some point fingerprinters used to identify individual
people, so now it just returns the standard voices on all systems evey if you have other voices installed
jcraig: so look at any aspect of the API that can be abused for fingerprinting will always be abused for fingerprinting. I haven't seen anything specific here, but I thought it was relevant
keithamus: there are a couple open issues I can lump together that I think we can defer. But I think braille support and speech markup we can design around those later
keithamus: the other thing is naming, I think we discussed notificationId, we can change. I think everyone is happy with the name ariaNotify, should we litigate priority?
jcraig: I don't think this needs to have aria, maybe accessibilityNotify
Jamie: accNotify?
aaronlev: I like ariaNotify, everyone knows it's related to accessibility. No one knows what AT is
jcraig: I like accessibilityNotify, it's longer to type
smockle: is it an accessibiltiy only feature, I coudl see someone who wants to use ear-cons who's not an AT user
Jamie: I think it should be aria, by virtue of it being a prefix like everything else. It's just simpler
Matt_King: no matter how broad the use is, it's still accessibility
cyns: and if I were making a setting in the OS, I'd put it in the a11y settings
jcraig: I think Leonie mentioned she'd just learned of the feature where having air pods in and getting a text message, you get it spoken to you. I can see a point to having a broader use case
jamesn: WE ARE DONE
<hdv> sarah: risk with making the use case broader is that it stops working as well , better to keep it accessibility specific
<ZoeBijl> zakim end meeting