zakim this is 92473

<annabbott> scribe annabbott

<Birkir> I am here now

aria-busy

<annabbott> MK: Brian asked the question about possible JAWS defect. Anything with aria-busy is removed from the page.

<annabbott> MK: Had conversation with Freedom Scientific (Rich also). Spec doesn't say how to render, which is normal for the spec. FS proports that if BUSY, JAWS shouldn't speak it.

<annabbott> MK: should there be something in APG for screen reader and authors as it's not used very often or very well.

<annabbott> MK: Question - how should APG address this?

<annabbott> MK: visually there is a spinner on page often.

<annabbott> Birkir: How should AT handle aria-busy?

<annabbott> Brian: Never found AT does anything useful at all.

<annabbott> MK: Chicken/egg problem. Under appreciated/under utilized in spec.

<annabbott> Brian: if it only applies to live regions...

<annabbott> MK: didn't think it has anything at all to do with live regions.

<annabbott> MK: (looking up in spec)

<annabbott> LW: paradox in spec

<annabbott> Brian: UAIG references aria-live, aria-atomic, aria-relevant

<annabbott> MK: description in spec and table of characteristics are out of sync with one another.

<annabbott> MK: UAIG text:

<mattking> WAI-ARIA has provided a collection of properties that allow the author to identify these live regions and how to process them: aria-live, aria-relevant, aria-atomic, and aria-busy. Pre-defined live region roles are listed in the Choosing Between Special Case Live Regions ([ARIA-PRACTICES], Section 5.3).

<annabbott> MK: aria-busy=true and aria-relavent=false have same affect

<annabbott> MK: misquoted on previous entry

<annabbott> MK: correction - aria-busy=true and aria-live=off have same affect

AA: If have aria-live can add aria-relevant and aria-atomic to indicate which part of the live region is announced. Have never seen aria-busy added into that.

MK: Can't imagine when you'd want to do that though.

AA: Is that why aria-busy doesn't work?

MK: No, the bug is with Jaws' interpretation. But I can't see whay an author would need to use aria-busy on a live region.

<annabbott> MK: there is not a required context on aria-busy. or aria-atomic or aria-live

<annabbott> MK: very curious as this is an end user experience issue

<annabbott> MK: scrap aria-busy as useless & dangerous part of spec?

<annabbott> LW: gets use case for loading. But does that automatically make it a live region?

<annabbott> MK: question: whether or not we should consider having characteristics of aria-busy rewritten so it can be used independently of aria-live.

<annabbott> Birkir: used for progress bar?

<annabbott> LW: visual designs do not appear as progress bar

<annabbott> MK: no accessible alternative for the visual design

<annabbott> MK: told FS that it needs audible ticks

<annabbott> annabbott: do you intend the ticking to overpower JAWS announcing of rest of page?

<annabbott> MK: if ticking is soft enough, yes

<annabbott> MK: when script modifies page right after page load as updating code (rawgit) to load page (respec) - never know when done.

<annabbott> KM: wishes AT would announce when done..

<annabbott> annabbott: SORRY - very green scribe here!

LW: The virtual cursor in Jaws jumps back to the top of the page, once the post-load scripts are done.

scribe Léonie Watson

Birkir: Wonder if the visual experience is the same?

AA: Depends if it's the whole page or part of the page loading. If it's a segment you get the spinning icon in that area.

Birkir: I'd like to hear the name of the component + the fact it was busy.

AA: Could label aria-busy?

MK and AA looking at Respec example to understand visual/screen reader experiences.

scribenick LJWatson

Bryan: There are pages where something is always busy somewhere - especially with complex web applications. A constant notification would be a distraction.
... My reading of the spec is that it would result in a notification once loading was complete.

MK: Birkir's idea to hear what was being loaded - like "Table loading" was good.

AA: What if multiple things being updated simultaneously?

Birkir: If you had the acc name included in the announcement you'd know what was busy/being loaded.
... Think the use case for multiple elements being loaded at the same time is minimal.

Bryan: Rendering happens in the background and once something is rendered it's beyond needing aria-busy.

MK: It's the equivalent of the visual experience I' thinking about.
... So when you sort a table, in the time it takes to redraw the table on the page, it would be good to know that was taking place - both visually and as a screen reader user.

Bryan: That usually happens in a split second though. Not sure what benefit it would bring?

MK: Sometimes it's not fast.

Bryan: Still not convinced there's a good use case.
... The question from the UAIG will be how should it be implemented in practice?

MK: It's already implemented - just in the case of Jaws it's done by removing the busy element from the page/acc tree until it's loaded.

Birkir: Think there are some use cases, perhaps not frequent though.

MK: The APG could/should give guidance on how to implement - as an author.
... Going back to live region - just make the content of a live region "Loading" or "Busy" until it's finished.
... Another advantage to aria-busy could be that the screen reader could know not to move the virtual cursor.
... When the loading was finished.
... Think an issue should be raised against aria-busy? Not sure we have strong consensus on how aria-busy should be specified though?

Birkir: Think we generally agree how it should work, but not that it's a big issue.
... One thing that holds us back a bit is lack of implementations or working examples.

Popup menu design pattern

http://www.w3.org/WAI/PF/aria-practices/#popupmenu

<mattking> Bug 27813 is for pop-up menu:

<mattking> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27813

Bryan: The design pattern doesn't factor in clicking in whitespace to open a context menu.
... Question was how that could be done accessibly? James' answer was that it shouldn't be done that way. It doesn't explain that in the APG though.

MK: APG says unlike a menu... it has no visible trigger. Is that true?

AA: There is no visible cue for a context menu.

Birkir: Because the browser context menu is the same whatever/wherever you click to trigger it.

Bryan: Thedesign pattern doesn't explain how to handle the document level context menu as opposed to element level context menus.

MK: I don't think we should put aria-popup on everything that has a context menu behaviour.

Bryan: Agreed.
... If have div to identify an editable region. Has custom menu attached to, so can click on whitespace and choose "Edit" from the menu that turns the div content into an editable region. In this scenario there is no way to indicate to AT users that the menu is available.

MK: There should be multiple ways to get to that editable state I think. Don't think we need to make clicking in whitespace kyboard accessible, but there should be a button for k'board users to perform the same function.

Bryan: Unless we handle this in the APG, authors will just assume they can do ahead and do the whitespace thing.

MK: Don't think the popup menu should be in the APG as it stands.

Birkir: It stands out as not being k'board accessible design pattern.

AA: ARIA spec says it's not necessary to use aria-popup where there is no visual cue.

MK: The description for popup is not best practice.
... Propose we remove the design pattern for popup.

LW: Does anyone think we shouldn't remove the popup design pattern?

AA: I disagree with removing it. If developers want to add something to the right click, if we delete it where do they go for guidance?

MK: The pattern is specifically about context menus not associated with a visible trigger. Either have to rewrite it to be about menus with visible triggers, or remove it. I don't know whether it's worth rewriting it though.

+1 to Matt's proposal.

+21 from Bryan.

<annabbott> +1

MK: Will add this discussion to the aforementioned bug.

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/ho that/how that/
No ScribeNick specified.  Guessing ScribeNick: LJWatson
Inferring Scribes: LJWatson
Default Present: Matt_King, +1.919.607.aabb, LJWatson, annabbott, Bryan_Garaventa
Present: Matt_King Léonie_Watson Ann_Abbott Bryan_Garaventa Birkir_Gunnarsson
Got date from IRC log name: 19 Jan 2015
Guessing minutes URL: http://www.w3.org/2015/01/19-aria-apg-minutes.html
People with action items: 

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