ARIA Meeting at TPAC 2018 -- 25 Oct 2018

<jamesn> https://github.com/w3c/aria/issues/806

role parity background

<mck> jn: in 2015 tpac, we agree that role parity was important focus for aria 1.2

<mck> web components said it was essential.

<mck> To have an aria role for all html elements.

<mck> correction: aria role or property

<joanie> https://github.com/w3c/aria/issues/696#issuecomment-363497911

<mck> jd: if goal is to accessibility parity with heml elements, then look at how html elements are currently mapped.

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity

<mck> jd: reads from wiki page.

<joanie> For web components purposes, what we are interested in is being able to create custom elements which present themselves to AT in the same way as these native elements. So for our purposes, the question is, e.g.: do ATs expose the difference between dfn and dt?

<joanie> If they do, then we also need a way to do so in web components (whether it be a new attribute or new role).

<tink> Minutes for the TPAC 2015 meeting with WebPlat WG https://www.w3.org/2015/10/21-webapps-minutes.html#item08

<joanie> If they do not distinguish, then we do not need any new roles or attributes.

<joanie> Similarly, e.g. do ATs announce "ordered list" vs. "unordered list" or similar? If so, we need to be able to induce that behavior for <custom-ordered-list> and <custom-unordered-list> web components. But if they just announce "list", then the existing list role seems fine.

<joanie> I'm unclear from the OP's summary which is the case, and am hopeful that those with domain expertise can weigh in to clarify.

<mck> jd: from a priority perspective, the aria wg deferred to web component experts.

<mck> Does anyone have the expertise to say that we do not need role parity in order to make accessible web components?

<mck> jn: Do we believe that web components are important enough to make role parity as high a priority as we have.

<mck> jd: If there is a disconnect then html headings and aria headings wuld be experienced differently.

<mck> We want equivalent mappings across the board for all elements to ensure interoperability.

<mck> lw: reminds that some elements, some elements, such as audio and video, may be difficult to gain parity.

<mck> So, there may be some small bits where we may not achieve it, and that should be OK for 1.2.

<mck> jn: We have a timeline for 1.2. The things that are done by that time will be in 1.2.

<mck> Things not done will not in 1.2.

<mck> lw: It will not slow down web components if ome of the parity is in 1.3.

<mck> ip: This is similar in some ways to the discussion of aria in html and what kind of flexibility is needed there.

<mck> It is important to understand that even if you have parity in roles that you do not necessarily have parity in experience.

<mck> example: you can have a link role, but a link with href will have a different context menu provided by the browser

<mck> but that is not an accessibility issue.

<mck> per say

<mck> jd: have consesus that role parity should be 1.2 priority.

<mck> ip: Uncomfortable agreement.

<mck> Web components do not prevent using native elements. You can use a native button in a web component for example.

<mck> If we have role parity, what is the benefit to the user if you could have made the element with native?

<mck> Not as simple as saying that devs will do the right thing.

<mck> jd: can we accomplish getting devs to right thing through authoring practices.

<mck> ip: perhaps.

<mck> ip: this is a validatio issue, not a rendering issue.

<mck> browser will render whatever you code.

<mck> jd: for authors who have a good reason for doing what they do, and the result is accessible, agree that is good?

<mck> ip: yes, but we are thne not encouraging native element use through validation.

<mck> jn: Why do we needrole parity if web components can be built with native elements?

<mck> lw: web components are a red herring.

<mck> stefan: Are we talking complete role parity with no exceptions, or parity with 100% of elements.

<jamesn> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity

<mck> Is it possible that web components require new roles that do not exits in aria today?

<mck> jn: the aim is to get role parity, but may not get there.

<mck> jd: if we cannot reach consensus, it will not go into the spec ... on a specific element, e.g., video.

<mck> jn: pasted link to list of gaps.

<mck> stefan: What if a web component needs a new role?

<mck> jd: People can file an issue asking a "foo" role if they need a "foo" role. that is not related to role parity.

<joanie> ack

<Zakim> Joanie, you wanted to say that this problem already exists.

<mck> stefan: what should they d in the mean time.

<mck> jn: work around the need as best they can.

<mck> jd: today, people can put role butt on an inert span. we already have that problem.

<mck> Yes, adding a video role could potentially make that kind of situation worse.

<mck> But, I don't think that adding the video role is making the problem significantly different from today.

<mck> dm: Is Ian's concern that people were most often break the first rule of aira, which is don't use aria unless aria is necessary.

<mck> ip: Yes, it is related to not making web authroing a free for all; it is related to authoring quality.

<mck> jn: So, we should not really care what is under the web component. that is the point, for the component to be a black box, right?

<Zakim> MichaelC, you wanted to ask about AOM use case and to say we need path to respond to new needs quickly; role parity means less in the way meanwhile and to say technologies often

<mck> mc: Since we started this discussion, the AOM has come forward with a rather convincing argument that we need a complete set of semantics for describing accessibility.

<mck> If aria does not provide it, they will have to create it, which would lead to fragmentation.

<mck> The AOM use case would need the aria semantics even in situations where aria is not needed in authoring.

<mck> If we achieve role parity, then we are better position for keeping current with evolving technology needs.

<mck> lw: how far through this mission are we?

<mck> jn: 3 roles are done.

<mck> not veyr far.

<mck> lw: The triage is done?

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity

<mck> jd: yes

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#specific-role

<mck> jd:as part of triage, we determine which elements need a specific role.

<mck> We have 16 that may need a specific role, 14 left to do.

<mck> Many of the rest will either be generic or we do not have consensus.

<mck> Let's say someone put a tabindex on an italic element, that would reauire an accessibility role.

<mck> Do we need a separate role for <b> vs <i>?

<mck> Many of think no, so we are thinking a generic role serves this purpose.

<mck> al: has there been discussion of exposing styling like highlighting?

<mck> example: a word is higlighted in a test ... user needs to act on highlighted word.

<mck> jn: It might be done with a generic role with an attribute that describes the styling.

<mck> we don't know if that will make 1.2

<joanie> https://www.w3.org/WAI/ARIA/roadmap

<mck> al: highlight made it on to my list of annotation use cases.

<mck> jd: We have a draft wg roadmap.

<mck> Included is role parity for 1.2

<mck> html attribute parity in 1.3.

<mck> highlight attribute 1.3 more likely.

<mck> We recognize that there will be aria attributes/props used to help gain html element parity.

<mck> ip: if role parity means we are being selective, then I'm more comfortable with it.

<mck> jn: generic is for a lot of things that do not have specific semantics.

<mck> And to michael's point, the fact that aria is host lang agnostic, I agree that parity is important.

<mck> js: Diff knowledge domains may require semantics that cannot be represented in html.

<mck> Sometimes traversal mechanisms need to be represented in ways that are not possible with html or css.

<mck> jd: I think we need role parity. A lot of math accessibility will ome with existing aria.

<mck> That allows knowledge domain expert to tell sr what to render.

<mck> So, for instance, we might want to keep aria-flowsto or have something similar.

<mck> I think we can address thses issues in parallel with and independent of role parity.

<mck> mk: it is not really role parity, it is html element parity.

<mck> tink: or html element mapping.

<mck> stefan: is generic 1.2 or 1.3.

<mck> jn: 1.2 for sure.

<mck> it is almost prerequ for most of the work.

<mck> mc: html elements is the 1.2 focus, regardless of whether they map to roles or props.

<mck> We are marching to a timeline for 1.2, not a specific set of features.

<joanie> Add new roles to achieve parity with HTML elements (Target: ARIA 1.2)

<joanie> Add new states and properties to achieve parity with HTML attributes (Target: ARIA 1.3)

<mck> jd: we are not changing the roadmap, right?

<mck> jn: yes

<mck> lw: we should have a resolution and a cfc

<mck> jn: not convinced we need a cfc

<mck> mc: we have come to broad agreement on the roadmap which is in the charter.

<mck> lw: why discussing here if we already had a cfc on the charter

<mck> jn: ok, i'm happy to do a cfc.

RESOLUTION: Work will continue on achieving parity with html elements per the ARIA WG roadmap.

<Stefan> Scribe: Stefan

(jn: introduction round)

Principles for how much the HTML spec should restrict use of ARIA

mk: open discussion to the web platform group
... put role on any element, browser would exactly what aam requires
... put anything on anything .. may or may not give a result, thats how ARIA works
... host languages can restrict what is allowed
... this is what we are talking about now
... there can be two different ends of spectrum, at one end we can say that we want to do everything possible, do not override native semantics
... at other end, goal of ARIA is disallow to disallow anything that break accessibility
... example seach button, ypi can break accessibilty here
... there are pros and cons for both
... remediate existing HTML is a pro of ARIA
... (brings examples)
... clever usage may improve accessibility
... dl with role presentation etc. will not validate - that doesn't help in real world
... question, it feels like we are forcing people making choice making accessibility where they can vs. beautiful code, is there a conflict between INCLUDING ACCESSIBILITY VS. VALIDATION?
... do I wanna validate or do I want to be accessible?

sf: i don't understand the reason how these rules were developed
... hickson defined a set of rules - pretty restrict
... we extended this later more flexible
... HTML5 spec there was move to modularization - we can do that too for the rules
... this was decided (ARIA in HTML)
... rather long discussion with detailed points
... define pattern for usage is nice idea - issue: aria authoring practices promoting certain patterns
... turning dt in heading is not good .. no advantage seen, no legetimation I can see
... all under discussion, going piece by piece

mk: the way it was coded based on the way ho it was done inside companies
... ok let's deparate discussions
... two different philosophies: allow anything that does not break accessibility (examples) why disallow that?

jn: (adobe homepage example)
... link with role=heading
... rsponsive design will even change the role assignments, too

sf: interactive link with static role

ms: restrict markup constructs is high bar to avoid breaking something .. restrictions are there for guys who don't know what they doing .. guidance avoiding constructs is important
... if you use constructs markup we rate as error cases .. its also degrading user performance in apps
... reqirements and philosophy behind nedds to be documented
... if you do something for a good reason simply ignore it
... if you know what you doing you can do whatever you want
... you also have filtering features .. you can filter some errors out if you like and you know what you are doing
... it is intended to be customizable

mk: what evidence do you want: one kind is prior art is justification, diffeent kinds of evidence
... good reason for doing_> vidence

jn: sometimes evidence is requested, it is standard process

mk: somebody needs to provide rationale why it is good idea

lw: we need lots of examles

mk: checker is a "validator"

sf: aria in html rules are NOT accessibility validation!

jn: can you give advice to third party validators?

Ian: validation is just a tool
... cases can be made without examples ..
... suggestion - w3c checker, is possibility for errors to add a NOTE: this isn't invalid, if used for remediation ok

jn: also my proposal

ms: ok thats very possible

jn: waring, error steps would be nice

sf: warning we have already
... default implicit semantics button on button is a warning but no error

jn: high bar with html spec, a lot of effort for a change

lw: we need more examples (20)

jn: chicken egg problem
... iw disallowed people won't do it
... wrong thing - we don't do it .. example missing

lw: examples of that thing being done .. where are they
... sometimes something is presented as problem but it is not

sf: bugs in spec based on examples are possible .. talk to me and we change spec

Ian: one person dictatorship should be avoided
... we should change process if this is the impression

ms: one person is always doing bulk of work .. need to convince him .. that's how specs are generaly developped
... checkers purpose is collect statistics on certain markup cases .. millions of request a day .. we can pretty quick collect statistics
... good sample to things to look at
... there are multiple mains in same document ..allow it! (example for requirement) ,, but number of BAD cases outnumbers number of GOOD cases

mc: so it remains forbidden

sf: w3c process allows companies involved to raise objections
... spec editor would always ask for a certain level of input that justifies a change
... spec its about preserving integrity

mk: so it is a checker not a validator .. using html checker as an accessibility validator is the wrong thing
... we should elaborate more on this

sf: lack of awareness where rules are and why they are used
... some things may make sense .. go through and file bugs and we do discussions
... rfc language .. must, should etc. may justify arnings

mk: an ARAI mut
... if it wreaks haoc
... havoc

sf: let's work together as in the past

mc: messaging destinations are hyperlinks, we can enhance info at target

jn: resolution?

SUMMARY: when issues are found they will be reported using the usual channels and specification owner will address it in a timely fashion

<david-macdonald> http://html5doctor.com/html5-check-it-before-you-wreck-it-with-miketm-smith/

<Irfan> scribe: Irfan

ARIA needs more interactive container role(s) with focusable/active non-presentational sub content

stefan: will bring some examples
... when we look at SVG model diagram, it is besed on some preconditions
... At supporting thw ARIA role model will not predictably on list items with keyboard focus causing many issues.

<Stefan> Stefan: Each class diagram is based on some fundamental preconditions. In the ARIA class diagram, the “left” input branch derived from generic widget (which combines input and command) brings activity in and the right branch generic structure. Also, the left branch consists concept-wise of interactive content whereas the right branch can have active content in the structure and is never “active” in a sense that it reacts on events and it is normally n[CUT]

detailed document for scribing sent to JD.

<joanie> Each class diagram is based on some fundamental preconditions. In the ARIA class diagram, the “left” input branch derived from generic widget (which combines input and command) brings activity in and the right branch generic structure. Also, the left branch consists concept-wise of interactive content whereas the right branch can have active content in the structure and is never “active” in a sense

<joanie> that it reacts on events and it is normally not focusable on its own.

<joanie> In addition, it was a precondition that on mobile devices, active roles triggered by tap activation are always and strictly 1:1 also in the keyboard focus chain. The other way round, structural roles should NEVER react on TAP events since they normally get no keyboard focus.

<joanie> While this separation made sense in the evolution of a first relatively simple class-based role model, actual platform and web development UI patterns considerably mix the different roles resulting in difficult “hybrid” roles that are not yet handled appropriately in ARIA.

<joanie> This includes, but is not limited to, list-like containers that have actions on the container and contain focusable sub content. As a consequence, for content authors and assistive technology evaluating the role attribute from platform API there is a potential source of confusion what will be an “author error”, what is in a grey area and what will be the “right” behavior. For instance: When will a

<joanie> list item be active? By consequence, AT supporting the ARIA role model will not react predictably on list items with keyboard focus causing many strange and inconsistent issues.

<joanie> Examples of Problems

<joanie> Listitems and Treeitems

<joanie> • listitem: not focusable (or not explicitely mentioned)

<joanie> • treeitem: focusable (since it also derives from option)

<joanie> • both class diagram concepts “clash” in a sense that in real life tree items MAY have interactive subcontent.

<joanie> Options

<joanie> • no level info

<joanie> • no possibility to group by property, just by structure

<joanie> • Reason: option derives from generic input whereas listitem derives from section.

<joanie> Windows 10 Power Options Dialog

<joanie> Hard Disk, Turn off hard disk after: On Battery (Minutes) Label + Numeric Spinner box

<joanie> Within this are two active elements, the keyboard focus is by default on the label and arrow right acts as value selector for the item focusing an numeric spinner (spinbutton)

<joanie> Windows Outlook “To:” address field with multiple names representing objects, not strings

<joanie> Within an input there is not a simple value but a list of objects (of custom role, representing people, distribution lists etc.). Navigation between these takes place using left/right arrow keys. The individual items are NOT static but dynamic (react on activation) hence making the input to something EXTENDED and DERIVED from input (since still text input is possible and also deletion/adding of other list

<joanie> members).

<joanie> Interactive lists with active subcontent in listitems

<joanie> Lists consisting of elements with role=listitem with active subcontent are common in Web UI’s.

<joanie> These are also present on touch devices, where the large region of the list item is used for activation whereas the interactive content may hold links or other triggers to related information.

<joanie> No selection is possible here therefore role=option is not appropriate.

<joanie> Role listitem is problematic since listitem does not allow for keyboard focus.

<joanie> Roles like link or button are also inappropriate since these forbid non-presentational subcontent.

<joanie> Proposals

<joanie> • New role=composite/generic, role =“InteractiveList” with “InteractiveListItems”

<joanie> • New “ListView” role (Example: Windows Explorer ListView)

<joanie> ◦ Contains focusable ListItems (rows) containing focusable subitems

<joanie> ◦ A ListView is NOT a Treegrid, these are different concepts

<joanie> • Alternatives

<joanie> ◦ Extend/subclass existing roles

<joanie> ◦ Fallback strategies?

<joanie> • NO Alternatives

<joanie> ◦ Grid role for 1-column is NO alternative (!) for a List with active subitems

<joanie> ◦ When you hear grid you expect x/y spatial navigation, NOT linear navigation

stefan: feel that we can use aria role description
... this is just a work around
... having a grid role for something that is only base on one cloumn, is not the best thing to do
... thats pretty much all.
... looking forward for the comment

<Zakim> jamesn, you wanted to say that some of these are layout grids

JN: came across similar problems
... its a hot problem..

been through number of different implementation and have found that grid is the only one that seems to work as of today.

scribe: i agree that it perhaps missing something

stefan: when you use grid role, it is based on assumption that you are having cells as part of grid that do not change their position which is not true
... when you aply RD principle, x,y orientation gets corrupted.
... this doesn't happen in grid role
... when you have a data table, you hav rows and column.
... rows may be combined but typically these cells do not wrap
... its not clever to use grid role
... I thought about using grid role but this is special use case.
... it can be solved but it is special discussion

mk: talk about grid then about bigger problem about interectivity
... about grid- there is zero assumption in grid that positions are fixed
... if you have skinny view port it becomes one column
... arrow keys works in same way in all the cases
... other thing about grid- when we have generic layout, there is not reason that grid has to be a regular. you can have 3 cells that are long and in next row you may have 6 rows..
... we cannot fully represent in current spec
... grid could do all of that.
... we can manually set rowindex and clomunindex
... respect to example in windows, it does not represent of tree at all
... it appears a flat interface
... you could make much more accesisble interface, if you could have used aria than whatever they are using.

stefan: its not a good example. you can do that with ARIA and HTML

mk: you could make a tree grid if you like one column.
... little bit more complex than we would like them to seen..
... native ones are not accesisble very well or they dont communicate any semantic at all.
... if you arrow across, you will hear content like file name, type...
... but you have a no idea if you are in a list view
... there is nothign in a11y API
... there is nothign to know that there are cells in rows

stefan: we can shift this discussion off line...
... need more to dig into it

mk: we currently have a way to build any of the UI that we are talking about and make them accessible
... they may sound sound different what you expect as sighted user
... wrote proposal in ARIA 1.1 property called aria interactive
... group came us with aria 2.0
... we anticipate implementing some way of communicating control pattern
... we need very specific proposal to add a new role.
... if you want a list view, you can propose a list view role.
... need to thing, how it will be meaningful

<IanPouncey> https://wicg.github.io/spatial-navigation/

ian: there is a community group

JN: whole grid can still be active for mouse user. you can do it and have another way as well
... may be we need to find a authoring pattern for this.
... lunch time.

aria grid role and row role properties required

<jamesn> scribe: CurtBellew

<jamesn> https://lists.w3.org/Archives/Public/public-aria/2018Oct/att-0015/Properties.docx

Stefan: naming data grids and layout grids the same is confusing
... ATs have to guess

<Zakim> joanie, you wanted to ask what the different AT behavior should be

Stefan: can a data grid focus a row?

mck: A data grid and a layout grid are the same. we define them so people know they can be used for either

Stefan: Don't data grids contains rows of data whereas a layout grid is to organize differing nodes

mck: I don't perceive a difference between them.
... screen reader will do the same thing in either case. Making a distinction - what would we like the AT to do differently

<Zakim> jamesn, you wanted to say that layout grids have no column headers or row headers

Stefan: is it ok to have row headers and column headers for a layout grid

jamesn: Row and Column headers represent a relationship between the data whereas a layout grid wouldn't

mck: telling a user that it's a data grid vs a layout grid doesn't help them

CurtBellew: wouldn't it be easier to understand the table immediately if you knew it was a data grid

mck: not necessarily . It's information you will get

joanie: Screen readers don't need to care

mck: Creating a new construct would add to the elements AT users have to use
... if all grids were represented as a table

Stefan: what about responsive design?

mck: user doesn't care

david-macdonald: layout tables vs layout grid

jamesn: a layout table isn't exposed to the AT but the layout grid is

mck: There are slight differences in the behavior between data grid and layout grid but they are minor

Stefan: there may be use cases in the future where this a change is required.

jamesn: please bring those issues forward

<scribe> TOPIC : do we need a property row type

mck: How do you hear all the content of the row? That's the problem we want to solve right?
... some screen readers have a command for reading the entire next row. but that's usually a command for tables

jamesn: a keyboard user can highlight the entire row. what's read at that point?

mck: you could : if the focus is in the first column then focus the entire row

jamesn: so then draw focus differently?

mck: calculate a label for the first row that contains all the data
... ?

joanie: if I get an event that says a cell is active or focused or the row is active or focused

mck: is there anything in the spec that says we can't make rows focusable?

jamesn: no

<Zakim> joanie, you wanted to ask for the specific values of rowtype and also ask for what the AT would do differently for each value

<jamesn> stefan: It is a string

<CurtBellew__> test

<CurtBellew__> jamesn: why not just fix aria-describedby rather creating something new

<CurtBellew__> Stefan: AT update could be difficult

<david-macdonald> http://davidmacd.com/blog/does-aria-label-override-static-text.html lists support for aria-describedby

<CurtBellew__> mck: if you have additional type information then how is the screenreader going to be able to separate that information from all the other information that's already announced

<CurtBellew__> mck: why not make this part of the rowheader label

<CurtBellew__> mck: aria-label the row header cell so that it has the additional informatoin

<jamesn> david-macdonald I don't see tr in that list

<CurtBellew__> mck: if the row has no label then you could put a column that is displayed off screen ....

<CurtBellew__> Stefan: sum or total rows

<CurtBellew__> mck: I don't htink it's a hack to add an accessible row header that is hidden

<CurtBellew__> Stefan: another best practice issue?

<CurtBellew__> jamesn: I think we should cover it with authoring practices instead of adding an attribute

<CurtBellew__> jamesn: if the practices are done form the beginning many of tehse problems are solved. In general , adding attributes takes a long time

<CurtBellew__> Stefan: this is long term. Just something to keep in the back of you mind. Frequent use cases that can be solved

<CurtBellew__> jamesn : encourage your developers to join the practices conversations

<CurtBellew__> david-macdonald: tested aria-label, aria-labeledby etc

<CurtBellew__> mck: be careful about logging bugs with screen readers. in cases where we don't have a canonical pattern

<CurtBellew__> mck: if it's focusable then the case may be different

<aboxhall> https://github.com/WICG/aom/blob/gh-pages/explainer.md

<boaz> :waves:

<david-macdonald> scribe: David

<david-macdonald> Test 123

<david-macdonald> scribe: david-macdonald

ALice: update on accessible object model

<irfan> agenda: update on accessible object model

Initial intention was to combine these use cases alalogous to the Dom

Walking the tree is too expensive

That he was walking the DOM tree

Were not doing that any longer but it should get in the way of these cases were trying to solve

If there was just a bag of properties what is a precedent between this and the aria properties

There are many issues that seem pointless to solve so that seemed better ways to do it. So we went back and we look at the actual use cases

Trying to solve problems that we've seen

Accessibility problems on the web that we cannot solve with aria alone

Right now ALice is going through the document that the link above and reading it.

Matt: please explain

Alice: you have a custom element of development in the page that may have some children. It's got nothing to do with the children but it's more like putting the role attribute on something.

Matt: so if you're extending a button and you will ride it in the custom element. If the custom element wants it to be something else, somebody who's using that custom element can interfere with those semantics if you cannot encapsulate those semantics

ALice: someone can still override them using Aria but you can't get rid of them is the goal

Michiel: is it fair to compare this to something like the onKeyDown attribute (which is what we used to use) where we now use an el.addEventListener?

Alice: that's a fair comparison
... id references do not work across shadow Dom barriers

Example found in case 2 in the document linked above

Developers find it annoying to sprout all of these ID references in order to make relationships

Matt: yes you have to have a lot of methods floating around sometimes dedicated to IDs themselves which is expensive

Alice: she's going through the examples in the link above
... so those of the five examples of use cases now I'll talk about how we are addressing them

Describedby would be an array of elements.

A there's still a relationship between the content attribute and reflected in the Dom I

Matt: what happens if you set up to an empty string

Alice: it's three lines security class down the one.
... conversation moving very fast always referencing the explainer which is linked above. It should explain everything
... the more likely version is the custom elements elementinternal object. This is a proposal to carry a bunch of information not just semantic but for participation it's privileged API, asthmatics would be part of the object

The most recent example of what that would look like, you would pass a needselementproperty of true.

Alice anything in the Dom will still take precedent and override it such as aria. This is all at the platform level and therefore at the Dom level its Greater precedents.

Alice: discussion of privacy. We had a discussion about this with the lawyers we thought we did get by with just firing fallback events. Potentially controversial and I'm interested in thoughts of the people in this room about that and it will depend on the area role.

We are also planning on introducing some new types for input event.

Scroll page up, Scroll page down, increment, decrement, dismiss

Michael: Big increment and small increment, such as an iPhone three fingers up versus two fingers up. Big jump up

Matt: think of the page of verses a small increments up.
... increment is just one step, and a multistep increment is an author defined amount
... in the JavaScript right now were listening for the arrow with the page of the page down. We have event listeners for those. Are you saying instead we witnessed list for increment event so he would have to change the code

Alice: I don't have a good answer for that, you could listen for both, you probably in the short term one listen to both until the shift happens. After the shift you may want to listen for the increment event. That would probably be my choice but you have the option

Matt: I'm curious whether activate was removed. One problem we are trying to solve. Screen readers their default like when you press enter on a button and reading mode it issues a quick make which makes it look like a mouse click. But when you click Enter and focus mode

Basically when you want mouse users and screenreader that have a different experience you have a problem in the and that they the screenreader looks like a math. So if we had an activated event screenreader issue so that the screenreader sending through what is equivalent to answer so that they can get keyboard experience instead of the mouth user experience it will be way better

I think it's just history but I don't think there's a better option for them because if they just enter a lot of thin times things are not the work.

With that wafer at the API level but was saying activate and if it does it could head answer and if it doesn't and would hit. We want a way to distinguish between keyboard and mouse and give the screenreader user the keyboard experience.

Alice: can you firebug against the AOM for this I'll drop a link

<aboxhall> https://github.com/WICG/aom/issues

It would be good to document this is a use case

Use cases are really really useful for all of this to so that we are not missing things

<aboxhall> https://gist.github.com/alice/15ac1f8f147bc0648957ccd52e6de928

Alice: I got some notes from the discussion that we had with Lainey Finegold about privacy which I've just dropped in

You can look at the reasoning that led to this decision

James: if you're on of iPhone what would a key event.

Alice: it wantn't do anything and that's what were trying to solve

James: Great

Alice: the input events thing came from Apple
... this here is just some ideas just my thoughts on virtual accessibility Nodes

It would have the area vocabulary would also have a bunch of extra properties. What extra information would you need to explain geometry position etc.

Focus ability anything that's not a Dom not without a tab index is not flexible

This part of the discussion is all in the explainer linked above

Matt: one challenge make a great screenreader experience is like where you never know where you keyboard focus is. Could we find out if the AOM would be able to provide like what we have us custom actions the native even nonstatic stuff.
... one of the things you can do some screenreader is you can select things that aren't folks of all I'm pretty sure most users can do that.

ALice: yes like select text

Matt: but if somebody does select taxprovide interactions within the and presumably you can do that just as well for screenreader. If the screenreader selection was equivalent to meta-selection. Today it's not.

<aboxhall> https://github.com/alice/aom/blob/accessibility-tree/accessibility-tree.md

Alice: the last use case was the accessibility three. So this point Alec over to another dock I started about standard sizing accessibility tree I started getting a questions. Problems that can be solved by specifying what the accessibility tree is having a predictable mapping from the top to any given accessibility API

The generic conception of an accessibility tree so across APIs your consistency

Allowing web platform figure authors to explain and predict what impact their feature will have on the accessibility tree

(Note: this is all described in the accessibility tree document linked above. This would explain how the accessibility tree relates to the DOM tree

James: as a short-term solution have the browsers to standardize

Alice: we discussed this. Even just computing the name, role, if the notice ignored her example display: none used to compute the name and role

Matt: when you compute the thing that references in as when you'd pick it up.

Joni: It never shows up in the accessibility tree is a object

ALice: there is inconsistency between browsers about which notes are included in the accessibility tree

Matt: the Aria spec is very specific about what is in the tree and what is not.

Joni: there are some things that must be included in a tree and a few things that must not be included in the tree and opened. A whole bunch of stuff in the mushy middle
... the only purpose of testing Accname what is the name calculated correctly there was a case one part of the problem was that on Apple the object was not included

James: we will not ask for an object that will not. If it's not in the trees shouldn't return accessible name for.
... To ALice, what do you need from us.

ALice: use cases for sure thoughts on area affecting Impacting behaviour events case.

Matt: if you go there where the rules will affect the behaviour...
... if the input is vents back going to be saying something like limiting the events that can be heard given its role.

ALice: the other way around it's going to say if an element for example. If focus is on the helmet with her own slider and use a person's right arrow key to get key down event for the right arrow you could before evidence for the for equipment and a key event for the right arrow

Matt: if a right arrow is received you will also get these other events because it has this role.

What if it's in HTML input type number

ALice:

yes

Matt: so might change the nature of the events. We want to make sure that anybody is using JavaScript is that their contract that they have with the webpages not affected by area. In this case these are new events so nobody was written JavaScript listing for the events will be impacted because all of the events are new

Therefore we are not affecting any existing contracts

Alice: this'll work where it didn't work previously so somebody following the APG it lower,.

Matt: it's always been really important that we can tell develop that adding areas of the webpage stuck and don't break your script. That's the most important thing. But because these are new events it sounds like it would be okay.

James: break time

<melanierichards> scribe: melanierichards

relation to HTML-AAM not obvious

<joanie> https://w3c.github.io/accname/#mapping_additional_nd_te

matt: right now, the accessible name computation is influenced by specs other than our AccName spec. there are multiple specs influencing the same calc, and that isn't apparent from our spec in some places. Even if it were, the question I have is: is that the way we want it? It creates problems of who's in control in some cases

<joanie> https://w3c.github.io/html-aam/#accessible-name-and-description-computation

matt: quintessential example is how title attribute factors in (can't remember most problematic test case)

joanie: the links I pasted in: 1st is acc name algorithm, 2nd is algorithm in HTML-AAM. probably makes sense to start with HTML-AAM. you'll see a whole list in section 5
... 5.1.1, various input types. [reads calculation rules found in this part of the spec]
... these two specs are interrelated. to me, HTML-AAM owns the accessible name of HTML. most of the time, they defer to us. If ARIA isn't doing anything here, what's the calculation? If only host language we were worried about, we could do something else here. But we also have SVG

matt: once we have HTML element parity in ARIA so we have all the semantics for that, then the ARIA AccName spec should be able to specify the way to calculate the name for any host language that implements those semantics. Therefore, HTML doesn't need its own accessible name rules.
... then you could have a single reference for how to calculate name
... maybe that's a longterm goal

joanie: maybe AccName 1.4
... AccName is an ARIA spec that can be overruled by HTML-AAM. The fact that they always defer to ARIA properties and thus use AccName makes sense to me. And if none of that applies, here's some rules

simon: I think there's a way it can be specified to make it clearer without being all in one spec. well-defined hooks from AccName into HTML-AAM.
... In other specs, like between DOM and HTML, there are steps in the DOM spec that are invoked by other specs, when they change an attribute, for instance.
... [looks for an example]

joanie: AccName algorithm is very complicated. What I would rather do for D...couldn't we just say, "otherwise, go off native language document" and then just stop the algorithm?

simon: issue is that ordering is different

matt: if you read HTML AAM, it assumes it's the starting point. And if you read AccName, same thing

joanie: but HTML AAM starts with if it has aria-label, go to AccName

<zcorpan> https://dom.spec.whatwg.org/#concept-element-attributes-change-ext is an example of an extension hook that DOM itself and HTML uses

joanie: they are not overriding us. ARIA takes precedence, if not, do some stuff.
... host language should own the host language, ARIA should own ARIA.

matt: some of the confusing test cases were a mix of native elements and ARIA

simon: I recently worked on a11y tests for the fieldset element. In particular, what the accessible name of the fieldset element is. In HTML AAM it says to use legend element except if there is describedby. In the AccName algorithm it also has something to prevent loops from happening. How that looping detection works, if you have a fieldset and goes to the legend, and that refers back to fieldset, not clear to me what should happen
... core algorithm seems a step behind in looping detection

[zcorpan meant labelledby, rather than describedby]

joanie: zcorpan's approach seems like something we should consider
... [invites zcorpan to make a PR] if appropriate, one for AccName and one for HTML-AAM. something quick and dirty at least for us to wrap our head around

zcorpan: I'll take a stab for one thing and then you can generalize from there

joanie: great
... HTML and other host languages should generally defer to us

<joanie> https://github.com/w3c/html-aam/issues/150

joanie: [story describing that patches are welcome to Steve/HTML-AAM]

jamesn: when you reference an HTML element and go to AccName, do you then go back to HTML-AAM for that element's rules, or do you stay in AccName

joanie: we have a problem where, if the author can't look at their markup and figure out what the name should be, and we the editors of the spec can't figure it out, that's an issue. We can't even agree on expected results and that's a problem
... we can try and handle every last edge case under the sun, or we can not. and we need consensus. bad things happen when we try to handle all edge cases
... if author gets 3 different results in 3 screen readers and gets different results and then just uses aria-label, what's the point of all this complexity

zcorpan: or they test in one, happy with the result, and then a user in another screen reader is confused
... can run a big query against HTTP Archive to find out how people are using various attributes
... I can search for that if I know what the question is

[discussion about Bryan having written a bunch of tests which helps harden code]

matt: could be that the code is more hardened than the algorithm needs to be
... there's certain complexity that you want to handle real-world use cases. There's a reason to have that complexity. But in general, most real-world cases should be intuitively obvious. And they become more obvious to people as soon as you explain self-referencing. How do you write the spec in a way that says these complex things are allowed, and these other things are not?

joanie: APG already writing best practices. maybe we should start with that, and generate tests from that. Do all the user agents even do that right? Iterate through and harden the algorithm. Maybe make some more complicated ones. At some point, maybe you Matt will come up with iteration 3 or 4, and we'll respond "nobody does that" and we can stop complexity there. Not sure if possible

matt: we have it in our list of to-dos for next year
... it would definitely explain labelling and describing using examples. Would we use those examples to try and figure out how to limit the spec?

joanie: hypothetically, can I right now if I take all your examples, turn them into acc name tests and find out what each user agent is returning for all the accessible elements there, and start finding out where there are discrepancies?

matt: I don't even know if we have one example that requires recursion
... they are the kind you can look at and figure out accessible name just from eyeballing it

zcorpan: another approach to go to Http Archive and find pages that are using these attributes and try to test those scenarios
... test against different screen readers

melanierichards: confounding factor is we don't always know what author is intending to do. we can make guesses. probably better than no data

zcorpan: at least can find non-interoperable cases and reason from these

joanie: can figure out if they're not interoperable because of UA bugs or because the spec is unclear
... I found in UA code here and there "the author probably meant to do ____" and that may or may not jive with the spec

matt: now that I look at section 5 of HTML AAM, let's say we have every single bit of these semantics in ARIA. Do we defer to HTML AAM for the acc name computation for these semantics, or we duplicate in AccName spec, or do we work all of these into the existing AccName calculation?
... once we have all these semantics, who's in charge of labeling them, us, or web platforms?

joanie: we are in charge of ARIA stuff, and also want to have interoperability. the label of the text box should be same for our role textbox
... [points to HTML AAM table where it says "use WAI-ARIA role"]

matt: you have 2 specs that do the same thing for different languages

david-macdonald: how much is ARIA used in SVG?

jamesn: should be if you have interactive SVG

david-macdonald: seems not ideal to be maintained in several different places

joanie: SVG has elements/attributes that are specific to SVG.

david-macdonald: maybe in the short term we let them take care of that and just file bugs against them

<joanie> https://www.w3.org/TR/svg-aam-1.0/#mapping_additional_nd

david-macdonald: seems like this might be working ok in the short term

zcorpan: markup languages don't turn up every year. Maybe we don't have to worry about anything else for now. Might not be unreasonable to have everything in the same spec, and have the other groups contribute

joanie: my understanding of hooks/extensions, you start with ARIA, if these things don't apply, you go off to HTML and SVG. If that's correct, why should we own their name rules? I don't think it belongs under us

matt: one of the reason it's different for ARIA is that aria-label and aria-labelledby are universal

joanie: we also have name from content and recursion

matt: does HTML AAM respect our name from content

jamesn: button element there says "use element subtree" (same from content)
... points out a place where not clear they're cycling back to us

zcorpan: should 5.16.1 be treated for misc "foo" elements? If so maybe this section shouldn't list any elements

jamesn: [reads out input type="text" rules in HTML AAM]
... some of the calculations in HTML AAM don't include generated content, even though we do in AccName

matt: bryan mentioned that, we don't know if CSS generated content is part of name from content

joanie: I think it is, though often you don't get to that point

matt: we had test cases with generated content, there was no other content besides generated content. It had a title and generated content. Had the gen content counted as content, it would have overrided title. But currently in browsers and Bryan's implementation, no one treating gen content as content

joanie: I think they are actually

matt: in 5.16.1, step 4, yield a usable text string. What does that mean? The browser returns the string "there is no accessible name?"

joanie: functionally means there's an empty string

matt: this wording is confusing

joanie: maybe file a bug to say "otherwise, empty string"
... looking at 5.1.1, I said step 2 cycles you back to AccName
... if the label has an aria-label, it refers back to AccName

matt: in other places they defer you back to AccName but in that specific place they don't

joanie: file a bug against HTML AAM

<zcorpan> info on how to run a query on httparchive https://gist.github.com/zcorpan/4684f8586b52638a75e661e8b75f27cb#gistcomment-2742582

jamesn: stuff inside people's firewalls will not be in it

<zcorpan> info on how to run a query on httparchive https://gist.github.com/zcorpan/4684f8586b52638a75e661e8b75f27cb#gistcomment-2742582

zcorpan: still a big dataset

jamesn: most of the stuff I work on doesn't appear in this kind of dataset. sometimes it feels like the things you work on don't count when people are analyzing use
... big systems doing complicate stuff, never ends up in these queries

zcorpan: when we removed showModalDialog from Chromium, global usage was really low, but it really impacted enterprise

joanie: if we have member orgs who are running up against that, maybe there's a way to make a quick test case and submitting that to the working group as a test case
... then we can get fixes from user agents and spec

<Zakim> joanie, you wanted to see if we could submit some internal test cases, sanitized for IP stuff

jamesn: when decisions are made via looking at data sets, that misses a whole chunk of stuff

joanie: the only way we're going to be able to figure out what these test cases are is to have them submitted to us publicly

jamesn: conclusions?

joanie: come up with test cases, figure out where the bugs are, file bugs, hopefully add hook/extension to make it more clear where AccName is deferring to native host language

matt: seems like we need more notes in AccName spec that basically point people to HTML AAM and SVG AAM to make it clearer that there are other specs that govern name computation

joanie: isn't that what the hook would do?

matt: not clear that you should start outside of accname
... can we get away with not having a normative dependency on HTML AAM etc?

zcorpan: depends on how we implement the spec hook idea

matt: host langs can't be the starting point for the tree because they don't say what to do with a div that has a role

zcorpan: we need to have a clear model of how specs are layered

melanierichards: also not clear to an author when an HTML element with strong native semantics has a role on it, whether you follow the HTML AAM rules or if you start from AccName for computation

joanie: I think you start with AccName

mattk: what if you have a role of spinbutton on input type number but not other aria-label/labelledby stuff, it doesn't say where to start

joanie: should HTML AAM section 5 say "if you have a role, start with AccName, if not come back here"

jamesn: I don't know how you get to the conclusion that you start with AccName

joanie: yes it doesn't tell you that now, it could
... hypothetically, section 5 should maybe say start with AccName
... then AccName should say "if nothing else applies here, host language applies"

jamesn: but something always applies

joanie: but if we have the hooks....

jamesn: so we change 2D to point out and stop there in the algorithm

???: is 2D in the wrong place?

zcorpan: point is that that step needs to be replaced with an extension hook

matt: might have multiple extension points to keep things in the right order

zcorpan: to comment on your suggestion to have a sentence at the top to invoke the other algorithm, I think that's a bit unclear way to write the spec. You can have a generic algorithm in HTML AAM that applies to all the elements. and that in turn calls into AccName
... currently have to read the entire spec to understand what all the steps are

[discussion about catching elements are that are not already defined]

zcorpan: that should have its own section

joanie: yes

matt: it does seem like our document should say "you always start with native host name document, and then come here"
... don't start at AccName, we need to say that explicitly I think

zcorpan: I think that's a reasonable way to layer the specs
... we need something to say what happens to an element not in HTML/SVG. Such as element in MathML namespace

jamesn: I know people who look at HTML AAM to know what to do, it's fairly simple to understand but AccName is not. I don't want to have to poitn authors to AccName

matt: I assume it's valid to use the label element to label an input that's been recast as spinbutton, but is it valid to use the label element to label a div with a role tree. That's not valid is it?

zcorpan: no

matt: I wonder if you coul create situations where it seems like you could use label element but it's not valid. a lot of things unclear to authors
... make it clearer what they can use where

zcorpan: label has association with specific elements, doesn't work if you try to use with a div, even if has text field role

matt: where did things land with people clicking on legend?

zcorpan: it was if you have accesskey, it delegates to first thing in the fieldset
... input role list, table, something not a form control and doesn't have a label relationship, I think there are authoring requirements that prevent it, don't think we need to optimize for that case

[people talking about how search role on button completely breaks accessibility]

zcorpan: if people do that and it breaks it, we should special case it

jamesn: would rather people just not do it

zcorpan: at the end of the day what we want it to make web more accessible to people, if a bad pattern is common, we can fix that in the spec

jamesn: spec or implementations?

zcorpan: both

matt: doesn't seem like we have consensus on where the starting point is for acc name computation
... some think AccName, some host languages
... at very least we need a note in AccName saying it's not the end-all, be-all. I prefer it say something like AccName is explicitly dependent on these other specs
... for special cases like div role="tree", they should have a starting point for that

jamesn: do we have any conclusions?

<joanie> https://github.com/w3c/accname/issues/35

[joanie filing issues]

joanie: going to go over to HTML AAM and file bugs about how every last thing isn't covered

- DRAFT -

ARIA Meeting at TPAC 2018

25 Oct 2018

Attendees

Contents

role parity background

Principles for how much the HTML spec should restrict use of ARIA

ARIA needs more interactive container role(s) with focusable/active non-presentational sub content

aria grid role and row role properties required

relation to HTML-AAM not obvious

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output