ARIA APG TF -- 11 Jan 2016

<scribe> scribe: JF

review updated radio group example

mck: looking for changes to the radio group example

jemma: jong has an example, but would like another week to produce something

jong: we've looked at this, and ther was no further comments

MB: we've looked at this

mck: so we can call this one complete

Review menu example

<jemma> https://rawgit.com/jongund/aria/master/practices/examples/menu-button/menu-button-1.html

JG: two examples here, lacks metadata

first example is a link, the second example uses the button element

the menu button is also a link, it takes you to another page

mck: menu items should be decendants of men

but not sure why a menu would be a descendant of the button

BG: spec notes that any child roles of button are automatically presentational, so youshould not put other roles inside of a button

mck: right, so why would you have menu items controlled by the button?
... first example seems unusual - not sure what is happening here

JG: if you hit enter or down/up, it should open the menu

mck: you can't overload menu buttons to be both a link and a button - not supported by ARIA

JN: have had UI requests like this before - hae provided hint text to advise to use the down button

mck: but it still acts like a link

JN: which is why we provide the hint text

<jamesn> Values of aria-haspopupValue Description

<jamesn> true: Indicates the object has a popup, either as a descendant or pointed to by aria-owns.

<jamesn> false (default): The object has no popup.

JN: want to return to ownership: when using aria-haspopup it needs to belong to something

jg: so aria-controls should be aria-owned?

<MichielBijl> www.w3.org/TR/wai-aria-1.1/

{yes}

<jamesn> Indicates the object has a popup, either as a descendant or referenced by aria-owns.

BG: contradicts descendants are presentational only

mck: if you add haspopup to button, it changes the role

might need to raise an issue against 1.1 spec

<mck> ISSUE aria-haspopup should use aria-controls instead of aria-owns for its relationship mechanism

ISSUE: aria-haspopup should use aria-controls instead of aria-owns for its relationship mechanism

<trackbot> Created ISSUE-1001 - Aria-haspopup should use aria-controls instead of aria-owns for its relationship mechanism. Please complete additional details at <http://www.w3.org/WAI/ARIA/track/issues/1001/edit>.

BG: need to also mention that the issue about 'presentation' is relevant, and is a problem elsewhere as well

there are other items as well that need to have the same presentation issue

mck: slightly off-topic, but you can raise that as an issue as well

<Zakim> JF, you wanted to ask if we need to file this with the ARIA WG?

mck: every button I've encountered hasn't required aria-owned

so this isn't an issue (is it?)

mck: there isn't anything that says you must do something when popup is present, but does it even matter?

do we need to add controls when the popup pops up?

BG: don't think so , doesn't do anything

mck: perhaps the issue is that aria-popup doeesn't require a relationship (?)

cpandhi: if the popup has menu items, how will they be related to the menu button?

mck: that's the question: what is the advantage of having a relationship?

JG: there is aria-controls - have a note to add aria-owns
... need to do this because there are multiple menus in the document, need it to differentiate

the question is... that we ask for the 1.1 spec to state that aria-owns not be required. change it to aria-controls and make it optional

"...optionally referenced by aria-controls"

<scribe> ACTION: mck to take Action 1001 and follow-through [recorded in http://www.w3.org/2016/01/11-aria-apg-minutes.html#action01]

<trackbot> Error finding 'mck'. You can review and register nicknames at <http://www.w3.org/WAI/ARIA/track/users>.

<scribe> ACTION: Matt King to take Issue 1001 and follow through [recorded in http://www.w3.org/2016/01/11-aria-apg-minutes.html#action02]

<trackbot> 'Matt' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., mgarrish, mking3).

<annabbott> Sorry, JF, I tried...

<annabbott> drats!

<scribe> ACTION: mattking to own Issue 1001 and will follow up with ARIA WG [recorded in http://www.w3.org/2016/01/11-aria-apg-minutes.html#action03]

<trackbot> Created ACTION-2002 - Own issue 1001 and will follow up with aria wg [on Matthew King - due 2016-01-18].

mck: spec does not have a normative statement that states authors must not include an HREF attribute on an anchor that has both role of button and aria-haspopup=true

spec is not that specific

you need to extrappolate to arrive at the conclusion that a conformance checker should do that

JF: agree that this is p[art of the authoring guide, does the spec need to be more explicit?

JG: are there other comments on this example?

mck: seems that this is such a common issue that perhaps the example should address it head-on

the best way is to say that if you have a link, that when you hover it shows a menu - best practice is that clicking the link - focus goes to first item in the menu (text)

so menu appears on hover and onfocus, but requires the trigger function to activate the menu

and enter sets the focus on the first item in the menu

AA: don't think the example works that way

mck: it doesn't... that is why we are asking about this as a best practice advise

BG: some people have filed this as a scripting error in the past
... asking about status of aria-help - it would be handy in a situation like this

mck: unsure of status

for now... let's do the simple fix: there is no href there, it just opens the menu

jemma: how would you change this?

mck: just take the href off of the link - make the very first item in the menu - make it go to that

IP: an anchor element without href isn't keyboard-focusable

AA; even with role=button?

IP: correct - this could be done with a span as well

JG: authors love anchor elements - this is a real world problem

IP: but this isn't a Best Practice - we should be teaching the Best Way

we can show the meaningless way as well, but wonder of the value

JG: we should use an exanple that shows this, and explain why it is either good or bad...

mck: we agreed early on not to show example of sub-optimal solutions

IP: if we start down that road, we will have a ton of examples that will need to be shown, not just here

<jongund> I need to leave for another meeting, talk to you in two weeks

discussion around making things focusable with "less optimal" ways

and how we document that

mck: if we determine there are many sub-optimal solutions, we could document that elsewhere and then link...

we could use <button> or <span>... the point being that if we sho0w the aria-attriubte in action, and note that it will do the same thing regardless of the element used

BG: didn't we do similar with role=button?

<jemma> https://rawgit.com/w3c/aria/master/practices/examples/button/button.html#

mck: Ian raised a point about re-usability of our code

IP: suggest that we use an anchor, but remove the HREF, but then you need to add tabindex... which means thta we could use a span just as easily. So use the <span> as the code example, but editorially note thta you can use any element
... notes that there are 2 use-case: roll your own or retro-fitting a11y into an existing implementation. In first case: "here's the best practice" - in the second instance.... we need to acknowledge it exists and offer solutions that work

suggested frame: Best Practice = "the best practice", followed by "Retro-fit solutions that also work" (perhaps ranked in order of preference, include notes where appropriate)

<jemma> Thanks for your points, Ian

- DRAFT -

ARIA APG TF

11 Jan 2016

Attendees

Contents

review updated radio group example

Review menu example

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output