W3C

WAI-PF ARIA Authoring Practices Guide Taskforce

16 Nov 2015

See also: IRC log

Attendees

Present
matt_king, James_Nurthen, jaeunjemmaku, Michiel_Bijl, Bryan_Garaventa, LJWatson
Regrets
Chair
Matt_King
Scribe
jamesn, MichielBijl

Contents


<mck> trackbot start meeting

<trackbot> Meeting: Protocols and Formats Working Group Teleconference

<trackbot> Date: 16 November 2015

<jamesn> scribe: jamesn

Review mixed checkbox examples https://rawgit.com/a11ydoer/practices/master/examples/checkbox/checkbox-3.html

<jemma_> https://docs.google.com/a/illinois.edu/document/d/1r5XNTLIZxCxyUZkqW2_4D1Nec1C8OHWOXPvRU7NqXxE/edit?usp=sharing

MK: should we have something in APG about browser support?

MB: limit to words but not numbers
... going to be a chore to update to browser versions

MK: we didn't make a decision to support major bersions of browsers
... our task is to provide practices which support th specification
... we need to make some sort of statement - find where we last discussed this
... pretty sure we made a resolution that we would not make an effort to update every example in response to eery screen reader or browser version change
... examples are not how to work around quirks
... best practices for compliance to spec. our expectation that browser and screen reader devs would use them to guauage their support for the design patterns
... recall that if there is some importatnt functionality that is broadly used and have to do something quirky we might include that but would not be our general practice

JN: 2 different examples - when things dont work completely and when things are completely broken

MK: i think the aria-labelledby example is slightly better for both NVDA and JAWS but the other works in some other cases and should be sufficient
... shoudl we create a bug for a section to draft our browser and AT approach

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29297

MK: in the example there is @alt on the mixed checkbox image
... there really should be null alt text

<jemma_> https://docs.google.com/a/illinois.edu/document/d/1r5XNTLIZxCxyUZkqW2_4D1Nec1C8OHWOXPvRU7NqXxE/edit?usp=sharing

Jemma: google doc for screen reader testing

JG: sometimes NVDA does read the grouping label, sometimes it doesn't
... with radios seems consistent, but checkboxes seems to be not consistent
... consensus to use fieldset/legend
... ?

MK: both are valid

JG: fieldset legend leaves it up to AT
... the 2 techniques will affect the user experience

MK: don't know if that will always be that way

<MichielBijl> JN: did you test between fieldset legend and role=group labelledby?

MK: looking at the spex we were 99% certain we can use fieldset/legend in this way

JG: that is intersting
... in the a11y api how is the FS/Legend exposed to at
... the AT finds the grouping label and then reads it
... think that is an interesting authoring issue
... the 2 techniques are saying different things about the accessible name
... the grouping thing is important in certain contexts

MK: the ATs should always provide access to the grouping label in all contexts even if they don't read it automatically
... all ATs have a command for reading the current element and its label and grouping container should probably get read there
... the only one that does that consistently is JAWS but not even sure that is accurate now

JG: shouldn't be comparing aria-labelledby with FS/Legend but should instead be comparing with role=group

discussion on if group works

JN: they should all be valid

MK: in the wild we see all 3 approached

JG: newbie devs want to overcontrol the experience
... they will latch on to the aria-labelledby example

MK: none of the screen readers are reading the grouping label from the currently focussed item

discussion of aria-describedby

JG: does role=group work for links

JN: no idea

MK: if you wanted the group to be a single tab stop
... Jon and Jemma will add a 3rd version with role=group

<MichielBijl> http://s.codepen.io/boomerang/a62554037b0f8d25269b06c245ea8e031447699204201/index.html

<MichielBijl> scribe: MichielBijl

MB: is this what we mean?

MK: we want to show the different ways to achieve the same thing
... we don't want to say how particular cases work
... what it's doing is explaining redundant code per spec
... redundant coding can produce redundant speech
... that could be a warning

JG: developers don't want to be redundant

http://s.codepen.io/boomerang/a478ae4e07dc1cb260899459db247af21447699453614/index.html

http://s.codepen.io/Michiel/debug/mevpMa

Zakim nextitem

Zakim next item

Review and update pattern work assignments and status https://github.com/w3c/aria/wiki/Aria-Authoring-Practices-Patterns-Status

MK: any updates?

MB: my name still shows after alert
... that is done

MK: no edits?

BG: there are more ways to trigger a alert
... you can add a role of alert to a div that is already there
... you can also add content to a div with role=alert

MB: do we want to implement different ways?

MK: alert developers of ways that don't work?

BG: if the alert is off screen it doesn't work

MK: maybe put in a note?

MB: rather show different ways of doing it than a note; that list might grow

MK: another way is to just unhide it with CSS
... is html5 hidden ready?

MB: you can use that, and have a fallback with a CSS attribute selector [hidden] { display: none }

MK: can you make that?

MB: sure

Review Landmark navigation pattern section of APG https://rawgit.com/w3c/aria/master/practices/aria-practices.html#landmarks

MK: for all intends and purposes this section is blank slate
... one choice is to not have a specific design pattern for landmarks
... Ann was pretty opposed
... we could have a design pattern here.

MB: landmark navigation could have inline links

MK: other parts of the APG

JG: I'm willing to take this on
... I can use this for examples

MK: do you wan't to work on the description?

JG: I will, and see what people think

MK: just take out te keyboard interaction section?

JG: yes, or provide a note

JN: “this is not your problem”
... we have much more important things to do and I'm in favour of removing it.

JG: I think it's important, people are confused about landmarks

MK: propose a description. I do tink we have some example work that is higher on the list.

JG: over the summer we have a new student helping us with the examples

<jamesn> don't forget we also have this in the APG

<jamesn> https://rawgit.com/w3c/aria/master/practices/aria-practices.html#h-kbd_layout

JN: can I get a task and just remove (X) from the spec?

MK: whole section doesn't really make sense

MB: I'm interested in what Jon comes up with

JG: I'll try to harmonise

MK: no, don't look at this. Write something, and we might delete this section
... do we need to discuss headings and heading level in the guide?
... we need to review section 4.2

Next item: be done!

MK: probably no meeting 21st and 28th of December

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/16 19:20:56 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JG/MK/
Found embedded ScribeOptions:  -final

*** RESTARTING DUE TO EMBEDDED OPTIONS ***

Found Scribe: jamesn
Inferring ScribeNick: jamesn
Found Scribe: MichielBijl
Inferring ScribeNick: MichielBijl
Scribes: jamesn, MichielBijl
ScribeNicks: jamesn, MichielBijl
Present: matt_king James_Nurthen jaeunjemmaku Michiel_Bijl Bryan_Garaventa LJWatson
Found Date: 16 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/16-aria-apg-minutes.html
People with action items: 

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


[End of scribe.perl diagnostic output]