<mck> MEETING: June 11, 2019 Authoring Practices Task Force Telecon

<scribe> scribe: AnnAbbott

<Dorothy> i also dialed in

<scribe> Agenda: https://github.com/w3c/aria-practices/wiki/June-11%2C-2019-Meeting

<Jemma> agenda:https://github.com/w3c/aria-practices/wiki/June-11%2C-2019-Meeting

Allow 1.1 values for aria-haspopup in 1.0 pattern https://github.com/w3c/aria-practices/issues/1025

Values of haspopup other than true for ARIA 1.0 comboboxes

<Jemma> https://github.com/w3c/aria-practices/pull/1029

<zcorpan> GitHub: https://github.com/w3c/aria-practices/pull/1029

mck: ramifications are it may/may not work with screen readers

Carolyn: works with many screen readers. Am using a dialog and seems to work pretty well, better than 1.1 which doesn't announce combobox

mck: JAWS only sees parent div

Carolyn: announces as text field

mck: doesn't see it in reading mode, announces as text field in forms mode
... if supported in pattern then 1) should be supporting in pattern and 2) possible problem with screen reader implementation
... currently is invisible in read mode and subsumed in edit mode
... if a grid is used inside of input, don't know how it would work

bg: if using aria-owns instead of aria controls, it works

mck: Microsoft objected at F2F meeting

<Jemma> what is "that" idea you mean, Matt?

<Jemma> "that" using aria-control?

bg: can we talk about this on Thursday?

mck: sure
... objecting to relationship between combobox and grid
... why do we need to call it a combobox?
... combobox needs autocomplete

bg: role doesn't define behavior

mck: don't need owns, just need controls

bg: have patterns for 1.0 and 1.1 that work
... 1.1 changed because of how it works

mck: spec says owns on edit and controls on parent
... compromise is combobox on parent div and screen readers need to implement
... then just need to fix 1.1 pattern

Guidance on Composing Effective and User-friendly Accessible Names

https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_effectively

mck: this section is not intended to be comprehensive
... thought is what we can have in this amount of words or less?
... requesting feedback in PR

<zcorpan> GitHub: https://github.com/w3c/aria-practices/pull/994

Jemma: really good examples

mck: need a tutorial - anyone who can help Eric with that?

Naming Guidance by Role

<Jemma> this made me smile

https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_role_guidance

mck: added through "C" alphabetically
... as model entries
... any reason to name alert?
... when would it be revealed? Where would you put name?

Carolyn: screen readers probably don't announce

bg: never seen naming an alert be effective

<zcorpan> https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_with_aria-labelledby

<zcorpan> <section role="alert" aria-labelledby="alert-title alert-code">

Simon: added example using aria-labelledby

Carolyn: tested with screen reader?

Simon: not tested yet
... but can use example for testing

<Jemma> <section role="alert" aria-labelledby="alert-title alert-code"> <h2 id="alert-title">Alert</h2> <p id="alert-code">code: red</p> <p>We're out of peanuts.</p> </section>

<zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6998

<zcorpan> alert "Alert code: red" (in chrome devtools)

<jamesn> shouldn't be landmark

mck: don't know what it will do in read mode
... may not get rendered
... doesn't think that adds any value
... div or section with role=alert without aria-labelledby won't be announced any differently
... NVDA implementation makes sense

Jemma: table headings need to be more descriptive

mck: long table headings are pretty annoying

<sarah_higley> I tested the alert with aria-labelledby pointing at its child, and it did read twice with both NVDA + FF and JAWS + Chrome

<sarah_higley> NVDA + FF read "content alert content" and JAWS + Chrome read "alert content content"

jn: looking at table, dev may get confused by "always"
... like an empty cell

mck: that's actually a bug
... maybe combine 2nd and 3rd columns
... likes having a single table for reference
... will come up with proposal and ask for feedback

Disclosure Menu Example

<Jemma> Table is intended for the summary. It should have a good description of table via table heading

<Jemma> https://raw.githack.com/smhigley/aria-practices/1028-disclosure-menu-example/examples/disclosure/disclosure-navigation.html

Preview link of disclosure menu: https://github.com/w3c/aria-practices/pull/1036

Sarah: arrow keys navigate as does home/end

<jamesn> logged https://github.com/w3c/aria/issues/993 based on cell/gridcell discussions earlier

mck: if menu closes, display heading that matches menu item
... activating link in menu shows heading
... closes menu

<Jemma> https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/examples/dialog-modal/dialog.html

Future meetings and other business

<Jemma> see verification result section from the example.

next meeting June 18 - Jemma will lead

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Matt_King AnnAbbott MarkMcCarthy BryanGaraventa Jemma evan zcorpan jamesn CurtBellew carmacleod Sarah_Highley DBass
Found Scribe: AnnAbbott
Inferring ScribeNick: AnnAbbott
Agenda: https://github.com/w3c/aria-practices/wiki/June-11%2C-2019-Meeting
Found Date: 11 Jun 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)