For #1021, we need to at least decide which milestone (1.3 or later).
If time, need to discuss in more detail.

I propose a single segment on the topic of "Effects of ontology on table and grid" for discussing approaches to resolving the following 3 issues:

• Issue Consider prohibiting name from contents for rows in static (non-grid) tables #1022: (Consider prohibiting name from contents for rows in static (non-grid) tables.
• Issue Should aria-selected be allowed on row, columnheader, or rowheader in table? #1008: (Should aria-selected be allowed on row, columnheader, or rowheader in table?
• Issue WAI-ARIA 1.1: Cell and gridcell #79: WAI-ARIA 1.1: Cell and gridcell, which proposes depricating gridcell.

I don't believe we need non-WG participation.

I think it will take a solid hour or more to clearly layout the problems and weigh options.

• Topic: Supported Combobox Implementation Patterns and mappings
• Time required: 90 minutes
• Outside participation required: No, except need HTML AAM representation.
• Issues:
  • The Combobox 1.0 design pattern references incorrectly include aria-owns instead of aria-controls. #998: The Combobox 1.0 design pattern references incorrectly include aria-owns instead of aria-controls.
  • aria-controls a required property for Combobox? #776: aria-controls a required property for Combobox?
  • Combobox: aria-controls or owns should be on input, not on combobox element, and only when combobox is expanded #716: Combobox: aria-controls or owns should be on input, not on combobox element, and only when combobox is expanded
  • Combobox has aria-expanded required, but there is a default value for aria-expanded #853: Combobox has aria-expanded required, but there is a default value for aria-expanded
  • Clarify combobox label placement #909: Clarify combobox label placement
  • Does combobox require an accessible name? #1046: Does combobox require an accessible name?
  • The ARIA 1.1 Combobox design pattern endorses unlabelled form fields as normative spec. #893: The ARIA 1.1 Combobox design pattern endorses unlabelled form fields as normative spec.
  • role combobox either misses text or is incorrect regarding role searchbox #742: role combobox either misses text or is incorrect regarding role searchbox
  • Update 'combobox' spec as per html spec/html-aam mapping for <select> element  #817: Update combobox spec as per html spec/html-aam mapping for <select> * [HTML-AAM: select element should map to listbox role regardless of presentation
  • HTML-AAM: select element should map to listbox role regardless of presentation html-aam#46: select element should map to listbox role regardless of presentation
  • Add aria-valuetext as a supported property of listbox #721: Add aria-valuetext as a supported property of listbox
  • Add aria-expanded as a supported property of listbox #722: Add aria-expanded as a supported property of listbox

There are several topics of discussion related to the above issues. I will organize them into an agenda for this segment.

• Topic: Long term planning for W3C explanitory resources related to ARIA and other web technologies
• Duration: 45 minutes
• Other groups: Web Platform WG, Education and Outreach WG
• Related issues: None, but could create one if @jnurthen thinks is appropriate.

Objective

Discuss long term options for making it easier for authors to get the practical information they need about developing accessible sites.

Problem

Currently, WAI-ARIA Authoring Practices,
Using ARIA,
WAI Tutorials,
and possibly other resources, such as some WCAG techniques, all offer valuable information to authors.
While there are some advantages to having separate resources, there are also significant disadvantages, especially to authors who fail to find relevant information simply because of the way the separate deliverables are scoped.
There are also downsides to WGs to having separate but sometimes redundant objectives.

I would like to discuss group related topics for 20 minutes, including:

• Use of group within list is unclear #1011: Use of group within list is unclear
• listitem role seems to be missing directory as required context role #1030: listitem role seems to be missing directory as required context role

• Topic: aria-details
• Time required: 45 minutes
• Required participants: DPub? Whoever is most dependent on aria-details.
• Primary issue: aria-details precedence over aria-describedby  #1009: aria-details precedence over aria-describedby

We had to pull aria-details guidance from APG 1.1 Release 4 because it is not clear when it is beneficial and what the anticipated screen reader support might be like. Initially, it was part of a section on accessible descriptions. However, it is unclear what the relationship between descriptions and details is. We need to answer some basic questions for authors, such as:

• If details is provided, can you also provide a description? Or, is it necessary to choose one or the other?
• What if a field has a description, an error message, and details? What is expected?
• Is there an expectation that details will be read automatically if associated with a focusable element and that element receives focus?

w3c/core-aam#52

Rossen has suggested Tuesday 11:00 - noon for a joint meeting with CSS, ARIA, and APA.
https://lists.w3.org/Archives/Public/public-apa/2019Aug/0027.html

We should reply to him as soon as we know this is doable.

EDIT: UPDATE: I replied stating the time is confirmed. Unless we hear otherwise, we should plan on this time.

I'd like to discuss aria-brailleroledescription. #924

DPUB meeting is 9-9.30 am on Tuesday.

I'd like to propose:

• Meeting with WHATWG HTML editors about HTML accessibility issues and improving collaboration between HTML and accessibility groups

Suggested time: Monday, right after lunch (14:00)?

cc @annevk @domenic @foolip @sideshowbarker @mcking65 @jnurthen

I'm interested in extending WebDriver with commands that take advantage of ARIA semantics and the APG. This could be a compelling incentive for developers to use accessible patterns.

My colleagues @spectranaut and @zcorpan will be available to lead a discussion at TPAC, and WebDriver editor @AutomatedTester has offered to lend us their expertise. Can we find 30 minutes on the schedule?

Yes. @jugglinmike Please suggest a time. Tuesday afternoon would be the easiest for us to move things around but other times may be possible.

Thanks, @jnurthen! How about 1:00 PM on Tuesday? (Really, any time will work for us)

@jugglinmike you got it. 1pm on Tuesday. @alice @cookiecrook not sure how this fits in with AOM but you might want to make sure you can attend.

@jnurthen is #1001 (comment) happening? There's a lot happening at TPAC so it'd be good to know.

@annevk @domenic @foolip @sideshowbarker @mcking65 @zcorpan we have a meeting about web components scheduled at 2 on Monday. We could do 2.30? How long do you need?

How long do we get? 🙂 I think we could likely fill whatever time we get, but don't know if people have conflicts. How about 45 min?

The ARIA Working Group just discussed Long term planning for W3C explanitory resources related to ARIA and other web technologies.

Since aria-braillereoledescription is being tracked as a PR, I'm duplicating my comments from the open PR #924.

Comment 1
At TPAC we agreed that this should not require (and should actively discourage) using "characters from the Unicode Braille Patterns block" because, in almost all instances, the web author will not know what these should be, even if they are an expert in braille.

As the simplest example, the web author has no way of knowing whether the user reads uncontracted (Grade 1) or contracted (Grade 2) braille, so this attribute would be formatted as a non-braille unicode string. For example, the screen reader could translate aria-roledescription= "denomination" aria-brailleroledescription="den" into the user's preferred Grade 1 (⠙⠊⠝) or Grade 2 (⠙⠔) braille rendering.

Other examples author-encoded braille strings include when a user is fluent in multiple languages, but only fluent in one variant of braille. For example, a member of my team is fluent in reading, typing, and speaking English, but only reads braille using his native German braille table. VoiceOver can provide that to him, but a web author cannot.

Comment 2
We also agreed that it may be okay to allow unicode braille with sufficient warnings, and no examples of this usage. The only context I can think of where this is necessary is testing, where a user may be learning tactile braille through remote instruction. E.g. a student learning the differences between US English versus UEB, in Grade 1 or 2.

Comment 3
I am skeptical of suggesting the unicode braille block is necessary even in the case of Math polyfills like MathJax. For the same reasons listed above, the polyfill can't know whether the user prefers to read Math in Nemeth, UEB Math, or Computer Braille.