Accessible Rich Internet Applications Working Group Teleconference -- 28 Apr 2016

<mck> Testing JAWS readback of typed info

<mck> not working, bummer.

<Rich> https://lists.w3.org/Archives/Public/public-aria/2016Apr/0218.html

<mck> testing again with JAWS 16 instead of 17.0.1962

<mck> scribe: matt_king

CFC results

<mck> keyshortcuts CFC successful.

<mck> RS: could possibly make changes to guidance language if Matt has APG section ready. Will pull in as-is for now.

<mck> RS: will take separate action to update based on APG after APG is ready.

<mck> RS: Joanie will incorporate language in editor's draft now.

<Rich> ACTION: Rich update aria-keyshortcuts based on pending APG guidance [recorded in http://www.w3.org/2016/04/28-aria-minutes.html#action01]

<trackbot> Created ACTION-2058 - Update aria-keyshortcuts based on pending apg guidance [on Richard Schwerdtfeger - due 2016-05-05].

<mck> Joanie: I will merge in keyshortcuts.

Password role

<mck> RS: sent message to security team.

<mck> MC: Their response was not a "lets meet" response. Seems like they are declining to meet; they do not see need; so we should go foreard.

<mck> RS: Last I heard from Brad is that he didn't have issues as long as we indicate to AT that it is a custom password field.

<mck> MC: I don't recall that last part about AT requirement.

<mck> MC: this discussion was not a publicly archived list.

<mck> MC: we should get something public.

<mck> MC: Reading from a note from Brad

<mck> MC: Does not clearly say we need to indicate that it is a custom password field.

<mck> RS: Perhaps I should write another note to Brad ans summarize a proposal and ask if it is acceptable.

<mck> MC: cc both web security and aria lists.

<mck> MK: What about using a boolean prop on text fields instead of a password role.

<Zakim> clown, you wanted to ask what the aria markup is for a custom password input that does not obfuscate?

<mck> RS: Prefer role as think it is simpler for author

<mck> rs: Léonie asked if 1.1 exit criteria could include 2 implementations by AT of the password role

<mck> Orca already does it so we would need only one more.

<mck> MC: Reluctant to add it as a formal exit criterion.

<mck> Janina: that is a slippery slope

<bgaraventa1979> I agree that this may be an issue

<mck> Joanie: agree it is slippery slope to go down that as exit criteria for AT

<mck> MC: Adding exit criteria for requirements that are not normative is not reasonable.

<mck> MC: Adding a normative req would raise a new set of issues.

<mck> Consensus: should not add exit criteria for screen reader behavior in custom password field (role="password") but that it is very important to seek screen reader implementations before ARIA 1.1 is final.

ACTION 2054 - haspopup

<MichaelC> scribe: MichaelC

<mck> http://rawgit.com/w3c/aria/action2054-haspopup/aria/aria.html#aria-haspopup

<mck> Revised aria-haspopup definition so that it specifies the haspopup value indicates both the availability and type of popup element.

<mck> Removed sentence: "This means that activation renders conditional content."

<mck> Reason: Activation implies default action. not all popups, e.g., context menues, open with the default action.

<mck> Changed this sentence into a note:

<mck> Note that ordinary tooltips are not considered popups in this context.

<mck> Added language to specify allowed values of menu, listbox, tree, grid, and dialog in addition to true and false.

<mck> Added language to describe how missing, empty, and false values must be treated by user agents.

<mck> Added language to specify that a value of true equals menu.

<mck> Added authoring requirements for keyboard accessibility and focus management.

<mck> Change properties table to specify the value as a token.

<mck> Added rows to the values table for the new allowed values.

<mck> Removed the following language about ownership relationship from values table, ", either as a descendant or referenced by <pref>aria-owns</pref>."

rs: unsure if we need menu

mck: could delete because values equal

but could be confusing to authors because of exception to being able to specify role

so want consistent for authors

rs: also say combobox should pull up menu instead of listbox

mck: no, because @@

because @@ is global is weird because could be put on anything

now need to make focusable

potentially to whole document?

rs: menu on body

mck: wouldn´t expect haspopup there

rs: if you want help, might want it

mck: need haspopup on some element, and not on every one

if put on doc, and whole doc focusable, AT needs to know

is haspopup really for this?

rs: it´s global, so can

mck: so then need to manage focus, indicate interactive to user

rs: concern about requiring focus

could just have keyboard handler

mck: how would AT tell user?

maybe a separate key property to inform of the key that activates the popup

<Zakim> joanie, you wanted to ask about the MUST NOT.

@@ popup activation

jd: why forbid exposing if value false?

mck: confusing to say is not there

jd: in platform mappings, may need to explicitly provide a value

mck: we did for current; maybe this is different

rs: @@ linux

jd: not by choice

mck: should empty be same as false? or ignored?

clown: in past, no value meant false

mck: ok, so maybe that´s a ¨should not¨ for AT

<clown> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaHaspopupFalse

<Zakim> clown, you wanted to ask what the default value for aria-haspopup is (is it false?)

clown: what is default value?

oh, see the false now

suggest wording of value descriptions to ¨indicates the popup is a menu¨

to avoid passive voice

fe: <missed>

jd: might need to include application as widget type

various: no

mck: but could say dialog is any sort of application

it´s your out, just another window

jd: ok, whatevs

clown: if there is an enumerated type, authors will try aria-haspopup=menu and expect it to work

rs: do we want it global?

mck: worry about putting on anything not designed to be interactive and focusable

putting on random node seems unnecessary, and if done has attributes of easter egg

so very confusing for screen readers

creates a whole new kind of problem

rs: can put tabindex on anything

so fair to say it must be keyboard focusable

jn: or via activedescendant

rs: yikes

clown: further expands what it can apply to

mck: have never seen on anything except a button heretofore

just worried AT has to keep telling user they can click on something they can´t move to

clown: just tab to body and hit F10

to get context menu

mck: not all browsers allow that

and rare screen readers intentionally focus body

bg: trying it out, get ¨has popup¨ notice on everything

mck: and then what if there are also descendants with popups

that´s nutso (literal scribing)

jn: we have use case for this

table with activedescendant

focus on header cells

mck: if were not global, can address that use case on grids

fe: use case where people look at text docs, pull out terms and relationships

there are focusable spans

<jamesn> anything in any of our SVG graphs could have a popup too

get a popup that tells relationships to other terms etc.

mck: why not have a link role?

fe: tells you additional info about that span

mck: button

fe: that seems to bend the role

mck: er, um

fe: e.g., walk to set of words, see it´s a term, look for other terms in doc that are similar

doing with buttons would be hard on reading

but you can get info about that term

mck: haspopup has been global for a while, and haven´t seen too much bizarre use

just checking if we have enough language

maybe can address in Practices

but the thing about focusable is agreed?

various: yes

rs: so seems values are ok

need to leave global

important to be focusable

rs: @@

mck: played with idea of key property

fe: why a separate one?

mck: popup keys are different from shortcut keys

e.g., a shortcut might move focus to the field, but another key open the popup

rs: could use describedby for now

mck: yeah, authors could if they wanted

fe: would author be wrong to use kbdshortcuts to describe the key that opens a popup?

mck: if popup is default action, no

e.g., on a menu

but confusing in other use cases

in use case of terms, which term opens?

fe: opens the one with focus

mck: shortcut key not really for the thing that has focus

clown: maybe down arrow is a defacto standard

mck: if you´re inside menu, you´re navigating

but can have sub-menus

clown: in which case you go right

mck: depending on layout

there´s also question of owning element

most menu buttons don´t work well if menu is owned by button

rs: also bad for dialog

mck: in combobox we use controls, but explicit for that role

I removed specfiying, and in cases where relationship is needed, should be put in

not part of the property

rs: are these changes ok?

mck: need to adjust language how values expressed

and change MUST to SHOULD for AT

RESOLUTION: Accept Matt’s proposal to change aria-haspopup for action 2054

ACTION-1490 combobox

<Rich> http://rawgit.com/w3c/aria/action1490-combobox/aria/aria.html#combobox

mck: haven´t circled back to this from haspopup

would need to update example code

and change default to listbox

clown: need to change implicit value

rs: clarify that if not a listbox, say so

mck: yes <thinks aloud the rewording>

rs: how substantial are these changes?

mck: can do shortly after call, update the branches

clown: @@

mck: implicit value means it´s required

rs: controls should be required?

mck: is; need to add to table apparently
...

clown: mapping needs update to fix errors

<clown> action-2056

<trackbot> action-2056 -- Richard Schwerdtfeger to Coordinate the mappings for the various AAPIs of the enumerated aria-haspopup values -- due 2016-05-17 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2056

rs: sounds like we´re good with these changes

ISSUE-1023

clown: will allow an item where difference is @@

rs: yes

in a big map, might put divisions in a menu

might not all be in DOM

does it hurt to include?

jd: could

finding practice confusing

and what if you have radiomenuitem and menuitem

how do the positions resolve?

mck: thought needed to support in spec

for mapping guide to be able to say anything

jd: don´t need that to be speced to calculate

bg: sometimes not conveyed unless explicitly set

and can have incorrect calculation

so think needs to be there

bad authoring, and can say so, but need a way to handle

jn: incorrect calculation happens with intermediate elements eg divs

rs: ok to allow author override

so ok to add?

clown: as supported?

rs: yes

<Zakim> jamesn, you wanted to say that the normal use is when the AT messes up the computation

jd: when I do the edit, will double check there are issues we missed

<Rich> ACTION: Joanie add aria-posinset, aria-setsize as supported states and properties to roles: menutitem, menuitemcheckbox, and menuitemradio [recorded in http://www.w3.org/2016/04/28-aria-minutes.html#action02]

<trackbot> Created ACTION-2059 - Add aria-posinset, aria-setsize as supported states and properties to roles: menutitem, menuitemcheckbox, and menuitemradio [on Joanmarie Diggs - due 2016-05-05].

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

28 Apr 2016

Attendees

Contents

CFC results

Password role

ACTION 2054 - haspopup

ACTION-1490 combobox

ISSUE-1023

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output