– DRAFT –
ARIA WG F2F (TPAC)

Introductions & Process Reflections

spectranaut_: Well - Change Request tracking

spectranaut_: Improve - Noticing good first issues

<spectranaut_> jamesn: doing well: testing!

<spectranaut_> jamesn: could improve: do things a bit quicker, get stuck halfway, have difficulty getting things through the whole

daniel-montalvo: well: testing ARIA-AT project - getting more data about what is supported will be great

mattKing: well: progress in clarity of the process about how we are working and getting the dependencies in PRs

mattKing: improve: how we move a concept from conception to maturity and look to see how this thing looks in practice from the beginning to the end in an organized way

Aaron: how we work better with ATs and coordinate the process - but also end up with what we want. AT are open to suggestions and we should hold them to some baselines. How do we coordinate with other WGs to get a11y baked into new standards to devs don't have to use aria

melanie: well: automated testing - lots of different perspectives representing different roles

melanie: improve: get tangled up in issues and allow us to ship more iteratively

Mu-an: improve - make it easier to find information

Mu-an: well - automated testing

Mario: well - very positive so far

<spectranaut_> marcelo: well - onboarding

Jean-Yves: improve - not always clear how the documents align

https://chat.whatsapp.com/Hf4HD1h6yyt4W257pHTBds

<AvneeshSingh> present

ARIA Math Role

<AvneeshSingh> Use case from publishing: https://github.com/w3c/publ-a11y/wiki/Accessible-inline-math

CharlesL: Publishers want to be able to create inline MathtML without actually using MathML
… They want to use plain text in paragraphs to convey maths
… We were looking at using ARIA role="math" to give screen readers semantics to pronounce all the necessary symbols
… Right now a lot of screen reader do not say anything when they see role="math"

Zakim: Is this the right way to proceed?

JamesN: What is the current state of support? There are current examples off alternatives to images that uses a formula
… How can we get AT to do the right thing? And can we use this as. Text?

CharlesL: Right now we have span role=math with mathml in the span, AT skips the math completely. Telling publishers that role=math is not needed and messing up AT

Charls: Currently publishers are putting a span with the math text

Matt: We had this in APG. What to tell people when there is role="math". We have nothing in there currently
… There is no clarity about what it is supposed to do
… We should probably deal with it now. If we are clear on what we should be putting in the spec and we can reach consensus, we should move forward

<Zakim> jcraig, you wanted to mention math type disambiguation, character disambiguation, the specific case clp mentioned, testability, and incubation

Matt: If you have real life use cases and we can specify what AT should do, then we should work with you on this

JamesC: Is role="math" in a container or in the actual text. I would expect it to be on the actual text. IF they put it in the container that wouldn't break anything

<Matt_King> /me give group some background on mathjax

JamesC: Math type disambiguation may be an issue
… There are screen readers, speech engines, and speech voices all of them pronouncing things differently
… I would expect hints rather than strong guidance on what to do
… There is also LateX attributes that need to be disambiguated.
… I'd rather focus on the testability. If we put something new and then we cannot reliably test it that's an issue
… At least to the level that W3C is doing it for MathML
… Recipy for success in the WI-CG is to get at least two browser vendors ad at least one screen reader
… Right now we are focused on the testability stuff

Matt: We are talking about three different ways of representing math. Are we on the same page?

JamesC: MathJax is a JAvaScript library that presents Maths with a self-voiced screen reader

Matt: Is MathJax requiring the math to be written in MathML?

JamesC: I believe so, at least for VoiceOVer to allow navigability

Mario: Without MathML you have no possibility to display math semantics. I don't understand how you can display anything a bit complex without MathML. You cannot display a fraction without MathML

JamesC: I think technically you can present any Math formula as long as you use parenthesis correctly using LateX

JamesN: MathML itself is ambiguous in itself

JamesC: Sometimes these are just images and they are now trying to represent those in an accessible way

Matt: There are some publishers that are writing Math but do not have the technical know-how to write MathML?

Charls: The rare different publishers. Big publishers and small publishers. Some are using authoring tools that do not support MathML
… These need a simpler solution
… We need to signal these to screen readers to pronounce that correctly

AvneeshSingh: Main issue here is the guidance. Most times these are very simple things in plain text.
… Is it OK to use role="math" in text? Should we use only MathML?

Matt: We cannot have clear guidance until we have clear expectations
… And until we have more on ARIA about what authors and assistive technologies should do

Goechel: There is a bottle neck in production. First it is produced in paper and then it goes to digital. We are loosing semantics in that process

Ashnib: For some of the authoring tools they may have plugins. For a short equation they could do without MAthML

Melanie: Would we want something more generic to cover Physics or Chemistry?

JamesN: WE are now focusing on math for now

S/are now/are/

JamesN: We don't have guidance for this now on the spec. Best way to move forward is to know if people thing that is useful. If that, please publication WG put a PR for us to discuss. Not meaning we would accept it, but at least we can start discussion

Matt: I think this should first be author-focused, then we'd work with AT

JamesN: I think we could do both at the same time

<Zakim> jcraig, you wanted to brainstorm some attrs: mathtype="latex | mathml", mathvalue="2/√(a+b)" (unambiguous string value)

JamesC: Maybe Math or MAthType, that could have a value of mathML or LateX
… And also some values to define what to speak
… These could be put on some incubation groups to start with

JamesN: This is trying to solve the simple Math process
… That would a good win if we can solver the simpler issues

Charls: Lates MathML specification introduce "intent", where you can have "chemistry", and also different areas of Math. The same equation can be pronounced differently depending on scope
… We could have role="math" intent="chemistry" intent="physics" etc

JamesN: We should be careful not to reinvent the wheel

JamesN: If you could start a PR then we can decide how we will approach this

Ashnib: Where should we be putting the PR and what it should include?

JamesN: It should contain some practical examples

<jamesn> s/https:\/\/chat.whatsapp.com\/Hf4HD1h6yyt4W257pHTBds\/TOPIC: ARIA Math Role/

How values are obtained

ISSUE: w3c/accname#184

<jocelyntran> melsumner: one of the challenges of accname: we've been reworking the order to what implementers are doing

<jocelyntran> ... for embedded controls, in computation steps

<melsumner> https://w3c.github.io/accname/#computation-steps

<jocelyntran> ... we're looking at step 2c

<jocelyntran> ... we should remove the bullet points in that step and rework it

<jocelyntran> ... we should have simpler examples

<jocelyntran> ... i dont like iii. the feedback we've been given. its confusing

<jocelyntran> ... we have a complex example in the doc, we should have a simpler example

<jocelyntran> jamesn: we cant just limit this to the accname spec

<jocelyntran> ... if we have something with role = textbox, what is the value of that div

<jocelyntran> ... have this spec become accname and accessible description and also the value

<jocelyntran> ... those embedded controls should say "return value"

<jocelyntran> ..spec should say how to get the value

<jocelyntran> ... that should be put elsewhere in the spec

<jocelyntran> Matt_King: embedded control is something different from what youre saying

<jocelyntran> ... in the case of an embdded control in the middle of a label

<jocelyntran> ... we're calculating the label elsewhere

<jocelyntran> Matt_King: we wouldnt call it an embeded control where we're getting the value from a textbox

<jocelyntran> mario: name is not the same as the value for some roles

<jocelyntran> ... we can compute the name by taking the content of the element

<jocelyntran> ... the content of the textbox row is not the label

<Zakim> jcraig, you wanted to say i also thought this session was going to be a proposal for a new "value computation" algo, but I wanted to hear what was proposed to replace this...

<jocelyntran> jcraig: we already have a name computation alg, im all for adding a value computation alg

<jocelyntran> ... what should we replace 2ciii with

<jocelyntran> melsumner: the proposal was to remove the lowercase 1, 2, 3

<jocelyntran> ... don't need extra bullet points

<jocelyntran> jamesn: all of this could go into a value computation alg

<jocelyntran> Matt_King: we don't even define the value of the textbox for iii

<jocelyntran> anne: is there an algorithm for determining a label's value

<jocelyntran> ... the label that needs to be read aloud should not include the input

<jocelyntran> spectranaut_: thats the accname algorithm

<jocelyntran> jcraig: in this case, the values are undefined and ambiguous

<jocelyntran> anne: ideally we would define in terms of the underlying concepts

<jocelyntran> ... not public apis

<jocelyntran> ... public apis can be overwritten

<jocelyntran> ... all kinds of side effects could be triggered

<jocelyntran> spectranaut_: for a native control, we should compute the value

<jocelyntran> anne: we should define it in a way where we return the value concept

<jocelyntran> melsumner: in this embeded control, we're talking about the control thats embeded in the label of a widget

<jocelyntran> ... we need to consider the textbox returning the content inside a label

<jocelyntran> s/context/content/

<jocelyntran> ... things like rich text formatting or content editable

<jocelyntran> ... there should be discussion about how thats read

<jocelyntran> ... should it be read like code or as its formatted

<jocelyntran> jamesn: can't we reply on html to return the right thing

<jocelyntran> anne: if you have a content editable dif, the user edits the notary itself

<jocelyntran> ... user is generating new nodes

<jocelyntran> ... no value concept there

<jocelyntran> ... if you want string output, get text content

<jocelyntran> ... dont always get great results from that

<jocelyntran> melsumner: if something has a list inside of it, they will only hear that

<jocelyntran> Matt_King: i wanted to clarify, in accname spec, we have a name algorithm, a description algorithm, when we replace the three subbullets, we should replace it with a third algorithm

<jocelyntran> jcraig: i support this proposal

<Zakim> jcraig, you wanted to clarify even contenteditable could be different depending on role...

<jocelyntran> ... for content editable, it makes sense to have a value computation algorithm

<jocelyntran> ... its different depending on the nodes inside the content editable

<Zakim> jamesn, you wanted to clarify that we are talking about Accessible Value not value

<jocelyntran> jamesn: I believe we're talking abut accessible value and not value

<jocelyntran> ... this is for accessibility apis only

<jocelyntran> spectranaut_: we should have a web driver accessible value

<jocelyntran> jcraig: we could have a separate spec, accval

<jocelyntran> anne: when would this be used?

<jocelyntran> spectranaut_: it would be used the same way as a value is used on an html element

<jocelyntran> anne: if you encounter a content editable, you might want something more complex than just a value

<jocelyntran> ... example a blogpost, it would read the whole thing, user might not want that

<jocelyntran> spectranaut_: this spec is for the browser also

<jocelyntran> ... the browser can calculate the value

<jocelyntran> jamesn: dont want to get cornered on content editable

<jocelyntran> ... could work on textbox, combobox, etc

<jocelyntran> anne: would be happy to review html part of the pr

<jocelyntran> mario: could we put a new attribute in some roles, something similar to html input

<jocelyntran> ... could we put an aria menu to get the value of the element

<jocelyntran> ... so that they can work like other roles

<jocelyntran> Matt_King: i wouldn't like to have a aria-value attibute

<jocelyntran> ... can't think of a usecase for that

<jocelyntran> ... if have aria-value equals some value, we dont want to have the author keep track of that value

<aaronlev> We already have aria-valuenow, for those places we need it

<jocelyntran> ... dont want two things to represent the same thing, out of sync issues

<jocelyntran> StefanS: if you have an aria value, for example a slider, that already has a value. too much confusion if you have 2 values

<Zakim> jcraig, you wanted to reply to aria-value and to use <div contenteditable aria-value="foo">bar</div>

<jocelyntran> jcraig: i agree with Matt_King

<jocelyntran> ... the idea in my example above, the author has to keep the values in sync, thats tedious at best, or even worse, could be abused to represent the wrong value

<jocelyntran> jamesn: assuming someone has good usecase for role=textbox, probably don't want to announce the children

<spectranaut_> jamesn: maybe use case for aria-valueid

<jocelyntran> Matt_King: lets get a value algorithm that is equivalent to what we're doing today

<jocelyntran> jamesn: we can probably solve the issues im talking about with aria-hidden

<jocelyntran> spectranaut_: who could do this work?

<jocelyntran> melsumner: action steps: remove bullet points from step 2c, rework step 2c

<jocelyntran> ... add example

<jocelyntran> ... start value computation algorithm proposal

ARIA Data Visualisation module

ISSUE: w3c/aria#991

<StefanS> James: Tring to tackle ths for long time with little process

<StefanS> James: want to get to something, taking a brief look what the state of th art is

<StefanS> James: HighCharts https://www.highcharts.com/ as an example

<StefanS> James: Charts with bunch of infos here .. visually we are not seeing much .. exact values .. besides of chart types (by gestalt principle)

<StefanS> James: they use aria-label on groups of that regions

<StefanS> James: whole bunch of things we provide metadata for

<StefanS> James: aria-label with year, all values with exact amount .. way mor info to screen reader user than for visual user

<StefanS> James: this is too much cognitive overload presenting this way

<StefanS> Matt: I cannot extract high level info this way from charts

<StefanS> James: I will put links in IRC later

<jamesn> https://www.highcharts.com/demo/highcharts/advanced-accessible

<StefanS> Aaron: hard to convey with lots of numbers ....

<StefanS> James: We actually ship things like this in our products at Adobe ... LIne Chart Insights we call that .. exploiting with AI what are major points in charts

<StefanS> AAron: useful for everybody?

<StefanS> Valerie: you can hover over to get same thing .. other mechanisms exist

<Marcelo_Paiva> no hover on mobile though

<StefanS> James: arrow through data points is also possible

<StefanS> Mario: is this really the thing for ARIA .. not sure

<StefanS> Mario: 3 steps for Accessibility: 1) what is it which type of graph (by string) 2) sonification 3) language to ask graph what is maximum etc. but what should ARIA do here?

<StefanS> Marcelo: What are best practices to represent a data set? James, very good practices shown .. its not about ARIA per se .. its about the entity .. visual bias .. how you can document best practices to present data to all users?

<StefanS> Gautier: we put role data as HTML table as acc. alternative .. side effect: more people get access .. annother benefit is structured data

<StefanS> JamesC: similar to math problem but much harder

<StefanS> JamesC: ambiguities ahead .. a lot of chart types are not even named .. so meaning is not obvious for everyone

<StefanS> JamesC: we need to have a format that unambigously lists all the data points .. want to demo one implementation .. shipping stocks app on iOS .. line chart .. (demonstrates app with VoiceOver on iOS)

<StefanS> JamesC: (moving finger over line chart on touch interface)

<StefanS> JamesC: (switches to a variety of rotors) .. AudioGraph you can describe chart metadata .. play the graph (spikes with different higher sound)

<StefanS> JamesC: (demonstates other cases) .. works also with gestures .. sound changes and you can get contextual data

<StefanS> JamesC: VoiceOver has access to all that and can do that therefore

<Marcelo_Paiva> more info on AudioGraph by iOS:

<Marcelo_Paiva> https://developer.apple.com/videos/play/wwdc2021/10122/

<StefanS> JamesC: this does not fit in ARIA totally but maybe we can take some of the ideas into a non-ARIA declaritive web API... maybe a strucrtured object property that the author could assign to an element or accessible node

<StefanS> JamesN: stock charts with million of points are different from charts with only some values ..

<StefanS> JamesC: type of chart should be represented

<StefanS> JamesN: some of things we can better than today .. what can we do to make that better?

<StefanS> JamesN: simple things we can do: we coud add axes, max/min vals, other criterias, grouping of data groups, anyway we can seperating this out and then AT can choose what to use in an organized manner

<jcraig> HighCharts multiple line example: https://sonification.highcharts.com/studies/line-text-desc-multiple/

<StefanS> Matt: ok the ideas are there to incrementally improve ARIA .. I would have done the implementation for Highcharts very differently .. colud be more consumable for AT ..

<StefanS> Mario: we describe something total visual for non-visual people but this is only one way to present the big data .. reseach should start from beginning not from the result ..

<StefanS> Marcelo: same issue as for alternative text

<StefanS> Marcelo: most of these charts are SVG .. static and dynamic .. we first should dicuss dynamic

<StefanS> Marcelo: .. and static graphs seprately

<StefanS> Aaron: limited scope proposed?

<StefanS> JamesN: Yes

<StefanS> Aaron: what is web percentage of charts ?

<StefanS> JamesN: we can'tz tackle everything

<StefanS> Aaron: let's start small I propose

<StefanS> JamesN: it can be called in graphics-aria not in main ARIA spaec

<Zakim> jcraig, you wanted to discuss the HighCharts multiple line example: https://sonification.highcharts.com/studies/line-text-desc-multiple/

<StefanS> JamesC: it fits in ARIA because of the name, it doesn't fit in role attribute and all that what associated with it

<StefanS> JamesC: bunch of good data in link example above

<StefanS> JamesC: its expected that author is updating model behind the scenes ...

<StefanS> JamesC: we don't a way to separately present it to screen readers

<StefanS> Aaron: I think we should do that in graphics-aria ... let's start with one thing that works

<Zakim> spectranaut_, you wanted to maybe highcharts would know about low hanging fruit

<StefanS> Valerie: knowing the metadata and correctly processing it is the key

<StefanS> Stefan: we need WCAG guidelines how the existing stuff should be used to descibe charts to be as author on the safe side

<StefanS> Stefan: this is not to say that ARIA cannot be extended to support here more

<Marcelo_Paiva> https://www.w3.org/wiki/SVG_Accessibility/ARIA_roles_for_charts

<StefanS> Marcelo: we don't want always start from scratch .. we need a clear direction how to attribute

<StefanS> JamesN: next steps? we need follow up with the highchart guys and assemble a task force

<StefanS> Aaron: Sounds that Apple has already has quite a lot to build on

<StefanS> JamesC: Testability is currently a big topic here

<StefanS> JamesC: FWIW, start incubator - any volunteers? Glad to help.

Proposal for "dashboard" and "tile" roles

ISSUE: w3c/aria#1994

<spectranaut_> issue 2: Proposal for "dashboard" and "tile" roles: https:\/\/github.com\/w3c\/aria\/issues\/2000

mario: ould like to discuss two new proposed roles

<Jem> w3c/aria#1994

https://github.com/MarioBatusic/Dashboard_and_tile_Roles/blob/main/dashboard%20%26%20tile%20roles.md

in many apps there are dashboards, but that conceptual design not always clear to screen reader users

dashboard could be a full web page or a partial page... the sections are sometimes called "tiles" or "cards"

would be good for an SR user to be able to navigate between cards/tiles

<jamesn> https://gist.github.com/mcking65/11882ebbe2889964c62ab5a16ab528c3

mario: related to Matt's proposal in the Explainer

StefanS: need to properly organize these via keyboard navigation.... if these could be region or another existing role, but with better keyboard support, would that be sufficient?

the arrangement is similar to a checkerboard, but they can be reflowed or scrolled indepenedently

<jcraig> s/indepenedently independently/

typically people apply list and list items to the cards, fails semantically and navigationally.

current roles are inadequate to convey the interactionability of the cardlist grid

listbox is even worse, because each can contain other interactives.

jamesn: not sure I agree with the names… tile/card/dashbioard, has baggage, but I agree that these are common enough to consider conceptually.

Matt_King: will talk about the dialog part later, but…

Matt_King: re the containers could be a more general purpose usage like the listview

<melsumner> kanban

<Jem> kanban

maybe something like the GitHub Kanban

could combine multiple listviews to make a kanban or dashboard.

melsumner: like the idea of a dashboard being a landmark role.. but why can't this just be a list and list items

StefanS: tiles are interactive on their own.... list items can be interactive, but then each card would contain nested interactives

melsumner: usually the list is the card, but you can put a link or some other interactive content inside it

<scotto> w3c/aria#1947

Matt_King: but in this case, the dashboard or card set is an interactive widget with focusable cards

scotto: @@focusgroup

scotto: not sure about the dashboard or tile role... maybe a good use for focusgroup containers

<melsumner> as a follow-up, I don't really understand what additional value the tile brings. I think folks generally use something like https://inclusive-components.design/cards/ but maybe this proposal simplifies it

there are a variety of these at common companies, but the primitives of focusgroup may supersede the need for new roles

Marcelo_Paiva: similar to the <article> tag

any content that can live on its own could be a reusable content type,... if not specifically a role.

StefanS: Matt asked what could a card represent

*lists variety of card examples* including a standalone one unrelated to the content near it

<Zakim> jamesn, you wanted to make sure we differentiate different types of "tiles"

jamesn: should think about differentiating different types of "cards" and "tiles"

one is just a block of info

sometimes just to display content.... other times using to selection a representation of a detailed view of the content that card represents

<scotto> linking to focusgroup explainer - https://open-ui.org/components/focusgroup.explainer/

Matt_King: proposal is related to some kind of collections

like listview, but we need to talk about what attributes would be needed

that seems to me like the area most people have been struggles with

curious about interaction with focusgroup

would we agree that each card would be its own focusgroup

scotto: seems so?

focusgroup is a promivitve ... the role doesn't matter as long as the keyboard works

Matt_King: use cases... navigate the collection,....... and the items inside the collection.

IIRC focusgroup is limited to arrow key nav, not containers tab nav

scotto: that is one of the open issues in the incubator

val: mnario are you up to date on the focusgroup proposal

mario: scribe missed answer

s./mnario/mario/

StefanS: taking up focusgroup proposal, should ARIA adapt this property, say adding an aria-focusgroup="grid" attribute will create a 2-dimensional listview grid with items organized in a responsive reflow grid order?

jamesn: how to cope with grid like navigation when basing it on matt's listview proposal

Matt_King: describes a nested matrix of lists

jamesn: so okay to skip entries within nested sets because of spatial navigation?

Matt_King: yes

jamesn: could be expected or unexpected by the user

jcraig: seems like a good reason for a new role

<spectranaut_> jcraig: I thought you were talking about existing list as views, but you are proposing something different that is a subset of what mario proposed?

<spectranaut_> Matt_King: instead of a generic role like list, we have listview, which is a more interactive list

Matt_King: instead of dashboard role, a more generic interactive list... maybe role="listview"

<spectranaut_> old listview issue from 2020 @StefanS w3c/aria#1325

<spectranaut_> 1?

<spectranaut_> r/1?//

Marcelo_Paiva_: listview listitems... cardview carditems... parallel understanding of these concepts

listview is more general... maybe sub roles

Marcelo_Paiva_: ordered and unordered too

<Jem> to ask about the distinction among window, dialog and newly suggested container which can have interactive component

jamesn: have you though about reusing the feed role for this?

e.g. photo gallery

Matt_King: that could work

StefanS: clarify?

jamesn: the feed is the container with lists inside

StefanS: I'm not convinced

<melsumner> P.S: it should be a stack of cards :shrug:

Jem: lots of author confusion between similar roles in ARIA spec... (window, dialog, etc) will this cause more confusion

<melsumner> I would like to bikeshed because I still don't think this is different than a list with listitems in it

<Jem> @jcraig I was trying to understand whether this new container discussion is relevant to "boundary" discusison Matt is proposing at the article, in particular, porous boundary.

Matt_King: to be continued during interactive lists discussion in the morning

Matt_King: maybe role description would be handy here?

jamesn: people use card or tile for all kinds of different uses. Some are groupings of information and some are selectable objects. Need to be careful we make it clear which we are dealing with and which we are not.

melsumner: tile vs card depends on what your designer calls it... this is a language/communication problem not an engineering problem

also can an interactive card have more interactives inside it?

Matt_King: yes

melsumner: I try eradicate nested interactives

gridcell is another example of a nested interactive

melsumner: I volunteer to help bikeshed

StefanS: the role itself communicates its keyboard usage

so it could be confusing to call a large interactive by a new role desc

melsumner: what about list as tiles or grid as tiles?

<div role="grid" aria-roledescription="tiles">

<Jem> I would like to suggest for us to come up with genernal conceptulization of this new container rather than talking about the distinguishing the various terms.

mario: could be large or small tiles

<Zakim> melsumner, you wanted to say what about "grid as tiles" or "article as slide" etc

this is what we do today... each row is like a single row. and you can move down across roles by column

sounds similar

<Zakim> jcraig, you wanted to respond to mels' grid ex

<spectranaut_> Marcelo_Paiva_: I was trying to remember xml tree cards and views cards and lists

jcraig: add on to Mel's with <div role="grid" aria-roledescription="tile grid">

<Marcelo_Paiva_> vcard

Marcelo_Paiva_: reminded of vcards

Rethink how "hidden" is aria-hidden content?

ISSUE: w3c/aria#1951

<Matt_King> github: w3c/aria#1951

Aaron: the 401k problem: we can't do anything for users when aria-hidden was used and the user is trying to access their 401k page. Critical information is hidden due to author error.

Author may use aria-hidden on body. There are many example of misuse.

The problem is that the information marked hidden is actually visible to other people.

One proposal: let aria-hidden=false unide the content.

<Marcelo_Paiva_> Scott has written about this - https://www.scottohara.me/blog/2018/05/05/hidden-vs-none.html

Correction: change so that if an ancestor has aria-hidden=true, chang browsers so that if a descendant has aria-hidden=false, it will unhide the node.

Today, browsers don't process elements that ar descendants of aria-hidden=true nodes.

We have broad agreement to change that.

<melsumner> Question: what is a valid use case of aria-hidden on the body element

<jamesn> https://w3c.github.io/aria/#tree_inclusion

Next mitigation proposal: If user focuses an area inside of a aria-hidden=true area, browser will unhide the elements in the aria-hidden=true area.

<spectranaut_> Matt_King: this is what I wanted to happen

James Craig: There are potentially other things that are hidden that should remain hidden and might be shown by the proposal.

jamesn: It was already an author error. And, we could do a console errior, right?

Aaron: Another mitigation proposal: On platforms that support it, if there is a hidden state in the accessibility tree, use that instead of pruning the AX tree.

This allows AT to access those elements.

JNurthen: the spec says the UA SHOULD NOT include the hidden elements in the tree. So, it is a should not, not a must not b/c of gecko

James Craig: We could let the AT have a trigger that tells the browser engine to show your hidden items?

Either solution requires work... The difference is mainly whether you do the work in the engines or in every AT. Another potential solution is to still prune the tree but give the AT a way to trigger the engine to hand over the hidden items.

StefanS: if a node is inert and a descendant has aria-hidden false, who wins.

Aaron: in our implementations, inert wins; it would be hidden.

Melanie: Why are 401k vendors asking for their errors to be fixed.

Aaron: it is the sr users that are asking. We try to help the users. It is hard to get every vendor to fix their web site. The users are blocked, and we want to unblock them.

<Marcelo_Paiva_> would it be appropriate to mention or acknowledge how role="none" impacts aria-hidden?

Melanie: I had to work in a univ dev dept where we often had to write code to fix content from vendors, why can't they do that?

<Jem> +1 to Aaron's philosophy..

Aaron: we just have compassion for the users. They often don't have anyone who can clean up the errors that are blocking them from accessing critical content that.

<Zakim> jamesn, you wanted to ask if we would expect all these things to remain authoring errors

JNurthen: would we still expect all of these things to be author errors?

James Craig: Yes.

JNurthen: these changes will not fix all the issues; it will improve situations and probably show some content should be legit hidden.

Aaron: who wants to write and review the PRs for these changes?

<spectranaut_> link: w3c/aria#2002

<jamesn> https://www.w3.org/events/meetings/c553e890-6d25-4945-9cfb-ea53cbfc3d3b/

<aaronlev> Here's a doc with the aria-hidden mitigations the group accepted:

<aaronlev> https://docs.google.com/document/d/1xC12DT74w9ozKzZYeUY5FlYddl8N7bqDn5yVdNYtAlc/edit#heading=h.s227idbjctx5

<aaronlev> @melsumner is going to help draft spec text

Definitive tooltip design pattern

link: w3c/aria#2002

<Mu-An> hi just want to know if this following topic around tooltip has anything/overlap to do with Open UI's attempt to create tooltips?

<Mu-An> related https://github.com/openui/open-ui/issues/815, w3c/csswg-drafts#8930

Matt_King: the question is what SHOULD role=tooltip mean

StefanS: also the developers have issues, I can present on that

StefanS: we have the tooltip role, and a pattern in the APG

<Jem> APG is Authoring Practice Guide for ARIA

StefanS: but accessibility tester says what about a link in the tool tip, what about modality,

StefanS: what about toasts

StefanS: what role should the toast have?

StefanS: what about warnings, errors, this are all examples of similar things

StefanS: (is explaining a document that he should upload somewhere)

<Zakim> jamesn, you wanted to react to jamesn

<Zakim> aaronlev, you wanted to say that in the very first ARIA (possibly pre-1.0), role=tooltip actually WAS for rich tooltips. For plain text tooltips you only need aria-description

aaronlev: when did tooltip become only for plaintext? it was originally for rich text. if you have plaintext use aria-description

aaronlev: you want to have role="tooltipdialog"? one of the things we came up with when we worked on popover - the issue with mouseover being the thing that brings up a interactive thing, is that it doesn't work for mobile or keyboard users

aaronlev: a button should open things that have interactive stuff

keithamus: when the focused, the tooltip will open. on monbile, an option can be added to the context menu

<Marcelo_Paiva> "Modals" require a user to take action before they continue. "Popovers" are small overlays that open on demand. "Tooltips" are floating labels that briefly explain the function of a user interface element.

jamesn: you discover hover on desktop

Matt_King: I don't think there was a change in the tooltip rule, if there was a change that we can roll back that is fine, there is one thing that I know for sure is that the tooltip role is NOT doing anything particularly useful

Matt_King: lets not add another one when we can reuse tooltip

Jaunita_: maybe webcomponents have evolved enough that not everything should be called a tooltip, a popup date picker is not a tooltip

Jaunita_: maybe we need to categorize what these are, and then give clear guidance on how to implement them successfully

Jaunita_: we have two use cases, interactive and non-interactive elements

Matt_King: I don't think we need to add more roles, we have enough roles, its a matter of what attributes we put on those rules, like aria-modal and other values -- could be useful on tooltip, dialog, datepicker, etc

<Zakim> jamesn, you wanted to say that I don't think there has been a change but i think it was never really implemented

jamesn: there is no change to the tooltip rule. it was never properly supported, to support richer tooltips

jamesn: I'm not sure if there would be an issue to add richer interactions to existing tooltip rules

aaronlev: it's really about what the AT will use with that information

aaronlev: provide information to at, that there is something there that is related

Matt_King: aria-controls is a pretty appropriate relationship here

aaronlev: what if the tooltip is not generated into the dom. popup-trigger=hover

aaronlev: browser can simulate an action

aaronlev: there is something that can appear with mousehover

Matt_King: isn't that the same problem as aria-actions?

aaronlev: that is generating a click, this is generating a hover

StefanS: you can only have one tooltip at a time

StefanS: this can be taken as a starting them

StefanS: tooltips are not focusable on their own

StefanS: but we want focusable subcontent

keithamus: I was hoping to clarify some of the points -- the ephemeral and singlton nature -- popover=hint is like this

keithamus: datepickers are just not related, they are diaglogs

jamesn: toasts are also different

Marcelo_Paiva: user research findings on tooltips, about static images, they are triggered by title attribute on images-- it doesn't work on modal, screenreaders users cannot copy the content, started to use figure or caption for images and data visualization

Jaunita_: when should people use title, and is it ever appropraite? only abbreviations maybe

Jaunita_: only for people using mouse

Jaunita_: we should have a new way to provide information that is useful to finish a process, not title

Matt_King: I'm still confused about distinguishing between the scenarios about how the user expresses their intent to get at the information. where you have a triggering button, that seems very straightforward. we are tripped up on hover and focus and long press -- the only usergroup that is left out is reading cursor that does not move focus...?

Jaunita_: also non-interactive content, like abbreviations

Jaunita_: images?

Matt_King: we can use aria-description for those thigns?

jamesn: jamesn: truncation of text, when we have long text and add "..." and we put a tool tip on it

jamesn: a keyboard user cannot get that information

Jaunita_: we don't want to give the user the option to activate it all

<jamesn> spectranaut_: What is the problem that is not being worked on in other areas

keithamus: on github.com, if you mouse over a user's handle, supplementary content which is a preview of the page of the user's main page. like safari on ios, long press to preview the tab. this isn't a dialog, we want them to actually go to the page, more than a tooltip

Matt_King: we came up with a solution/design pattern -- every persons name and everything has the same thing you are talking about -- what we decided to do was change the default action on the link, if you click once it is a hovercard which puts the focus on the destination link inside the card, then you can press enter twice to get to the destination

Matt_King: if you press once you get the hovercard information

Matt_King: we made an option within the accessibility settings

Marcelo_Paiva: one more issue with tooltips, users who have low vision, the tooltips adhere to the scale

jamesn: non-native tooltips are ok, another reason not to use title

Marcelo_Paiva: popover is different

Matt_King: we don't have a pattern in the APG that address the use cases that stephen outlined in the beginning, at least, not all of them

Matt_King: if one of the primary gap is how do screen reader users trigger hover or focus, I'd like to know

jamesn: one question for you Matt, the tooltip patterns that we do have that aren't published -- we hadn't come to consensus if these examples actually solve problems

<Marcelo_Paiva> https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/

<Mu-An> w3c/aria-practices#127

Jaunita_: is role tooltip actually necessary, what is it use for, and if so how do you make is accessible

<Jem> https://github.com/w3c/aria/wiki/TPAC-2023-ARIA-Meetings

<Jem> I would like to suggest to add a note about the resoultion (or action items ) at the end of discussing the meeting topic in above schedule table,

Notification API, how to move forward

<Jem> doug: I will do some intro and Aaron will take the stage.

<Jem> ... live regions - discoverble screen reader users - survey to developers - difficulty to get information from live regions in a consistent manner as well as overusing the live region

<Jem> complexity of liveregion dom, updating the dom, and lack of consistency by differet screen readers.

<Jem> off screen dom case can cause confusion whether is discoverable or not...

<Jem> .... we came up with proposal, notificaiton api

<Jem> to solve these problems - lack of consistency, lots of complexity...

<Jem> ... interested in learning how to move foward

explainer: https://docs.google.com/document/d/17kKNoCIoMSFMFicz0wSQR-PHWHfHGYfz1WdtHMYyrhE/edit#heading=h.r83mzc4f0o33

<Jem> aaron: did you also talk to AT vendors?

<Jem> doug: I talked JAWS - creating UI for notification

<Jem> .. ATs are on board to move on this efforts since there are so many notification

<Jem> jaunita: How live region and focus management will interact together(?)

<Jem> aaron: we are trying to get feedback to sophisticate the live region and create prototype to upgrade original intent and design

<Jem> ... bar is low to implement ?

<Jaunita_> We might want to address the problem with frameworks not loading fast enough for focus management techniques to work

<Jem> steps: 1, turn on flag by testing with one AT and One browser

<Jem> step2:(next stage) - get the feedback and cooperate feedback

<Jaunita_> Often that’s why devs are over-using live regions

<Jem> step:3 origin trial -6month ( people sign up and using the prototype..)

<Jem> s/step: 1/step1/

<Jem> ... goal is creating the minimum viable product

<Jem> only implementing in the AT who really wants to implement

<Jem> ... I suggest Doug to create minimum feature set, not including whistle and bells for now.

<Jaunita_> There might be some challenges implementing this on top of complex applications built with common frameworks

<Jem> .. we will work with notification API, test, get feedback.

<Jaunita_> Managing multiple regions needs to be more predictable too :)

<Jem> marcelo: what are you tring to solve alert from live region,?

<Doug> WICG/proposals#112

<Jem> aaron: instead of DOM , it is js API

<Jem> ... vision option to cancel the region, providing alternative methods and so on

<Mu-An> https://github.com/WICG/aom/blob/gh-pages/notification-api.md @Doug is this old or basixally the same thing?

<Jem> aaron: notification api wilil allow different kinds of info sharing.

<Marcelo_Paiva> dropping link for context: https://www.baeldung.com/rest-api-error-handling-best-practices

<Doug> https://github.com/WICG/aom/blob/gh-pages/notification-api.md - this is old

<Jem> mu-an: there is github doc and I see the intent of creating prototype. wht there is a delay?

<Jem> aaron: focus on solving high level implementation with MS, rather than solving edge cases and sub level issues

<Jem> jaunita: does the notification can solve problems of unordered object?

<Jem> aaron: lots of questions can be answered once we implement the prototype

<Zakim> jcraig, you wanted to ask where the latest explainer is? The Google Doc doesn't include much of the feeedback previously given, and without a GitHub explainer or spec, it's hard to file as issues.

<Jem> jaunita: how this will solve unloaded dom?

<Jem> aaron: developer will solve this problem 

<Jem> jcraig is talking about API explanier doc.

<Doug> WICG/proposals#112

<Jem> doug: there is new doc which I updated.

<Jem> WICG/proposals#112

<Jem> jcraig: quesion about unordered parameters

<Jem> aaron: we will try to get support and feedback. about the process I shared with the group.

<Jem> aaron: we can test it later.

<Jem> stefan: how resolve conflict which uses live region and notification API at the same time?

<Jem> dough: notification API can still slip in and we can work on clarificaiton further

<Jaunita_> Will this break existing live regions at all?

<jamesn> benb: will platform APIs need to be modified?

<Jem> aaron: I may need to change platform API

<Jem> ...I can test that with google

<Jem> keithamus: the first version; author will have to do capability detection, in this case, live region becomes fall back option

<Jem> ... you will see the demo that works which works with existing browsers and AT

<Jem> and then

<Jem> ...demonstrate how and often notification id will be used

<Jem> keithamus: is there a way to cancel notification api insteading of writing new one?

<Jem> doug: Narrator example, you can do flusing something out if you have a priority

<Jem> for another notification API

<Jem> aaron: current live region have problem informing types of notification - users can choose which notificatioin omitted or not including priorities

<Zakim> jcraig, you wanted to mention for demo purposes, this could be prototyped on Mac without any AT change... Not a permanent shipping solution, but faster than the alternatives.

<Jem> doug: notification api allow filtering as well as depending on speech API - braile

<Jem> aaron; Jcraig's question above is interestingn idea.

<Jem> janita: how live region and notification work together?

<Jem> aaron, dough: there will be a documentation including queueing info...

<Jem> doug: there is no queuing in theory.

<Jem> doug: order is ????

<Jem> doug: window has already other notification apis and it will go smoothly coordinating these

<Jem> aaron: response to Mu-An,

<Jem> ... inconsistency of api implementation notification can happen depending on AT

<Jem> ...but it will always read the msg.

<Jem> mck: it is related to interoperability by screen readers

<Jem> .. AT project's goal

<Jem> marcelo and Jcrag: the details of technical implementation dicussion

<Jem> jamen: we will focus on big picture, how to proceed this proposal

<Jem> aaron: if you want to get involved with the efforts, AT developer, users, implementers, let us know

<Jem> Jaunita: I would like to get involved with the proposal