Meeting Minutes for Monday, 24 April 2017 ARIA Authoring Practices Task Force

The minutes for today’s meeting can be found as text in this e-mail or at the following URL: 
https://www.w3.org/2017/04/24-aria-apg-minutes.html


JaEun Jemma Ku, PhD
Internet Applications Systems Specialist
University library
University of Illinois at Urbana-Champaign
424 Library, M/C 522
1408 West Gregory Dr.
Urbana, IL 61801
1-217-244-2145
jku@illinois.edu
http://a11yfirst.library.illinois.edu/ 
 

W3C
- DRAFT -

ARIA APG TF

24 Apr 2017

See also: IRC log

Attendees

Present
JaEunJemmaKu, JamesNurthen, AaronLeventhal, ShirishaBalusani, AnnAbbott, matt_king, jongund, Bryan_Garaventa
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Jemma
Contents

Topics
Matt: Update on treeview review; 3 critical bugs found.
James: Update on modal dialog pattern revisions
Matt: Update on fixes to modal dialog example
Aaron: Update on issue 132: Changes to treegrid example code
aaron's update
Summary of Action Items
Summary of Resolutions
<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.

<AnnAbbott> https://github.com/w3c/aria-practices/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A%22Jan%202017%20Clean%20Up%22%20sort%3Aupdated-desc%20%20label%3Abug%20tree

Matt: Update on treeview review; 3 critical bugs found.

<mck> https://github.com/w3c/aria-practices/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A%22Jan%202017%20Clean%20Up%22%20sort%3Aupdated-desc%20%20label%3Abug%20tree

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.

James: Update on modal dialog pattern revisions

<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

Matt: Update on fixes to modal dialog example

<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


Aaron: Update on issue 132: Changes to treegrid example code

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

aaron's update

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.

Received on Monday, 24 April 2017 18:17:04 UTC