See also: IRC log
<scribe> scribe: Jemma
<AnnAbbott> presesnt+ AnnAbbott
take up item 1
<sirib> can you put the link to the issue?
matt: thanks everyone for working on this. this can be closed.
next item
<AnnAbbott> https://github.com/w3c/aria-practices/issues/144
There are 2 more issues that I have noticed. (I realize that these are visual issues, however I think it's important to fix them because we need sighted devs to want to use these accessible controls). Issue 1 When moving a mouse horizontally across a menubar, hovering over each menu button to see what is in its menu, each newly-opened menu appears instantly (good) but the previously-open menu hesitates before closing, which looks like both menus are open [CUT]
for a while, which feels really odd. This odd behavior does not happen when I use right/left arrow keys to traverse through the menus. I looked at the code to see what could be causing this, and I found this code in MenubarItemLinks.js:
I don't know why there's a timeout here - is it necessary? If it does need to be kept for some reason, then 300 ms is way too long to wait before closing the previous menu, so we need to determine what minimum value it can be set to.
Issue 2 Using either keyboard or mouse, when the user opens a menu and then traverses to a menu item inside that menu, the menu button in the menubar no longer looks selected. For example, open the Font menu, and arrow down to the Serif menu item. The selected look of the Font menu button disappears. This is different from the look of a desktop menubar, which would show the Font menu button as "pushed in" (for Windows menubars) or "blue" (for Mac menubars)[CUT]
http://w3c.github.io/aria-practices/examples/menubar/menubar-2/menubar-2.html
<mck> here is the example:
<mck> http://w3c.github.io/aria-practices/examples/menubar/menubar-2/menubar-2.html
jon: if there is no delay, mouse
user will be frustrated
... but i can remove it
... change it to 100?
james: the problem is existing menu still stays open when new menu is opened
jon: I can look into the issue
matt: we can ask Carolyn MacLeod
to fix this problem
... can anyone add comments to the issue and assign this to
her?
jon: she can contact me any time for any questions.
next item
<AnnAbbott> https://github.com/w3c/aria-practices/issues/326
zakim take up agendum 3
matt: aria expanded can be
optional as it was stated in the spec
... jon has already submitted pull request for this change
jon: student is doing an example
with active decendants
... I would like to finish all the examples before I move away
from ARIA-APG including html 5 menu example
matt: I also need to make some
editorial changes
... we would be able to finish this in the current
milestone.
matt: It seems that left arrow
behavior and modifier issue are all fixed.
... browser default action can be applied here.
... enter key does not work for me
<aaronlev> i have the mac info
<aaronlev> cmd+enter opens link in new background tab, and cmd+shift+enter opens in new foreground tab
matt: control +enter and shift +
enter key activate links and open the links
... I raised aria current issue but it can be dealt at next
milestone.
<AnnAbbott> https://github.com/w3c/aria-practices/issues/325
james: I made a quick change to
it
... added one sentence to clarify that the interface can only
be controlled by elements that are descendents of the
dialog
... I changed master
<mck> https://rawgit.com/w3c/aria-practices/master/aria-practices.html
<jamesn> https://rawgit.com/w3c/aria-practices/master/aria-practices.html#dialog_modal
<jamesn> For all dialogs, all controls required to operate the dialog are child nodes of the element which has role set to dialog.
jon: if we put role tree item to a link, keyboard does not work
in particular, chrome browser
matt: jame's edit can go to under state, property section
james: I can move it to state property section as one of list items
<jamesn> https://github.com/w3c/aria-practices/commit/aaa85366e3516be91da4dc5c50027553b3995d8e
this is the change james made, All controls required to operate the dialog are child nodes of the element which has role set to dialog
https://github.com/w3c/aria-practices/issues/321
matt: issue we are taking now is
"we cannot scroll all the way to the bottom in order to press
the buttons. It bounces back and I cannot activate them."
... as a solution, we made Modal Dialog to Make Full Screen on
Small Devices
... let me know what you think - it works on ipad and
more.
... I did 1. Add momentum scrolling. 2. Make dialog layer same
height as main window.
<AnnAbbott> Group to review issue 321 this week. https://github.com/w3c/aria-practices/issues/321
matt: James, please provide feedback on this.
jame: yes, I will
this is part of next milestone
<AnnAbbott> https://github.com/w3c/aria-practices/issues/132
aaron: how different tree grid
from tree is the starting point for the work this week
... different from grid
If the treegrid is configured so that rows can not be focused, then the first cell controls the expand/collapse behavior. In this case, aria-expanded will be on the first cell in each row instead of on the row.
Current work on this example is now in the treegrid branch of w3c/aria-practices at: https://rawgit.com/w3c/aria-practices/treegrid/examples/treegrid/treegrid-row-nav-primary-1.html
<AnnAbbott> Group to review above rawgit link above this week.
aaron: This same example can be
used in three ways. Rows are focused first, but cells can be
focused: Useful when we want to present the treegrid to act
primarily like a tree. Cells are focused first, but rows can
also be focused: Useful when we want to present the treegrid to
act primarily like a grid. Only cells can be focused: Useful
when we we are primarily a grid, and we want to simplify the
user experience by removing row navigation options.
... if whole row is focused, it acts like tree
... when only cells are focused, it is like a grid.
jon: by the way, it was a false alarm in regard to tree role to a link.
aaron: I appreciate the feedback from the group.
<sirib> Now it is working with enter when cell is focused
<AnnAbbott> Feedback requested on interaction mode.
siri: why is there aria-readonly="true"?
aaron: I added note about
that
... note is in the example page. aria-readonly: in ARIA 1.0, a
grid/treegrid is editable by default. However, there is no
default in ARIA 1.1. Firefox currently implements the ARIA 1.0
concept for this, which means that "editable" is read for every
cell unless aria-readonly="true" is used on the treegrid. There
needs to be some follow up with user agent developers on this,
as ARIA 1.1 seems to be treating it more a tristate (don't
care, false, true). In a[CUT]
... a bug was filed on the spec regarding aria-readonly but it
is possibly invalid.
rrsgent, make minutes
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/it/ keyboard/ Succeeded: s/browsser/browser/ Succeeded: s/item/items/ Present: JaEunJemmaKu JamesNurthen AaronLeventhal ShirishaBalusani AnnAbbott matt_king jongund Bryan_Garaventa Found Scribe: Jemma Inferring ScribeNick: jemma WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 24 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/24-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]