RE: Minutes for Monday, 12 September 2016 ARIA Authoring Practices Guide Task Force

Hi Stefan, thank you for your feedback. I’ve provided some responses for your consideration.

 

Schnabel, Stefan <stefan.schnabel@sap.com> wrote:

>In the examples, the focus directly enters the grid cell when it contains active elements.

 

First, please read the ARIA 1.1 specification for grid.

http://w3c.github.io/aria/aria/aria.html#grid

This behavior is consistent with the 1.1 specification, which was written based on TPAC 2015 discussion, many follow-on ARIA telecom discussions,  and several conversations with screen reader developers.

 

Stefan continues:

>This is in contradiction to the proposed ARIA 1.0 APG behaviour where focus always stays on cell and F2 will put the cell in an edit state or transfer focus to the inner cell content. 

 

You may still implement the 1.0 behavior all the time if you think it yields the best experience for your application. The requirements are "SHOULD" statements, not "MUST" statements.

 

Stefan continues:

>since screen readers will need to look inside in the former case to find out what’s in and look one level above to find the cell/column label association in the latter case. 

 

When focus is on a cell, screen readers do not look inside. In this case, the browser calculates an accessible name from content, i.e., the cell content gets stringified. So, when focusing on a cell, eventually screen readers will typically speak an accessible name for the cell plus metainfo like row/col indexes and/or row/col titles. 

 

When focus moves to a widget inside a cell, eventually screen readers will typically speak that widget as it would be spoken if it were not inside the grid plus metainfo like row/col indexes and/or row/col titles. This is the advantage of focusing on the widget; the user can get the role/state info because it is not wiped out by the name calculation. When we were working on the new grid specification, screen reader developers told us that looking up the AX tree to grab metainfo about the cell is already part of something they do so not a big deal. That said, there is work to be done here and that is one thing I will be pursuing with screen readers developers.

 

Stefan continues:

>Anyway, currently we have to write tons of extra code for Jaws when focus is on the cell to detect the inner element role and its values. 

 

Wow, I hope you are not doing this. Calculating the name is the browser's job. Of course, if you want to put aria-label on every cell, that is up to you, but mixing roles inside of labels is a truly horrible idea.

 

Stefan continues:

>We need to know if this will change in future and if this change will come by concept or by screen reader improvements.

 

I am commited to helping get good support from screen readers. 

 

BTW, having reference implementations that can be used by screen reader developers is one of the reasons for making the example code part of the APG.

 

Stefan continues:

>Also, we think that the current vizualization of the editable state 

>for text in cells  is suboptimal in the examples. 

>The design of the examples should strieve for multiple interaction channels.

>The behaviour should be either Excel-like or Access-like 

>but not a mashup of both scenarios. 

 

Since grids that contain a mix of editable and static content are very common, the goal of the visual treatment in example 2 is to provide a clear visual indication of where interaction is supported. In Monday's meeting, we discussed adding more examples where all the content is editable.

 

Stefan continues:

>Finally, we think that focusable header cells for grids should be generally allowed by concept no matter if the content is interactive or not.

>The examples are inconsistent here, too. Example 2 contains focusable non-interactive header cells.  

>You will run into perception  problems if you do mixup things here.

 

There are good reasons for both models. This is a design decision, and the APG offers demonstration of both approaches to help people understand both. Individual authors may adopt the pattern most appropriate for their applications. More info on this topic and other aspects of the examples will be added to the example page before it is complete.

 

Best,

Matt

 

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Tuesday, September 13, 2016 12:53 AM
To: James Nurthen <james.nurthen@oracle.com>; public-aria@w3.org
Subject: RE: Minutes for Monday, 12 September 2016 ARIA Authoring Practices Guide Task Force

 

Annother thing that must be discussed more is the general focusing paradigm for x/y grid keyboard navigation.

 

In the examples, the focus directly enters the grid cell when it contains active elements.

 

This is in contradiction to the proposed ARIA 1.0 APG behaviour where focus always stays on cell and F2 will put the cell in an edit state or transfer focus to the inner cell content. Also allowed event propagation (can we press space when focus is on a cell containing a checkbox to check it etc.)

 

We shall be *crystal clear here what to do as mandatory*, since screen readers will need to look inside in the former case to find out what’s in and look one level above to find the cell/column label association in the latter case. 

 

Anyway, currently we have to write tons of extra code for Jaws when focus is on the cell to detect the inner element role and its values. We need to know if this will change in future and if this change will come by concept or by screen reader improvements.

 

Allowing both implementation versions is an option but I feel doing so we will end in discussions like those for combobox.

 

Also, we think that the current vizualization of the editable state for text in cells  is suboptimal in the examples. The design of the examples should strieve for multiple interaction channels.The behaviour should be either Excel-like or Access-like but not a mashup of both scenarios. We can give more details on this if you like.

 

Finally, we think that focusable header cells for grids should be generally allowed by concept no matter if the content is interactive or not.

The examples are inconsistent here, too. Example 2 contains focusable non-interactive header cells.  You will run into perception  problems if you do mixup things here.

 

Best Regards

Stefan

 

 

 

From: Schnabel, Stefan 
Sent: Dienstag, 13. September 2016 09:15
To: 'James Nurthen' <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com> >; public-aria@w3.org <mailto:public-aria@w3.org> 
Subject: RE: Minutes for Monday, 12 September 2016 ARIA Authoring Practices Guide Task Force

 

Hi Matt, James,

 

In the data grid examples, 

 

http://w3c.github.io/aria-practices/examples/grid/dataGrids.html

 

there seems to be no keyboard navigation possible at all when using Internet Explorer 11 on Win 10. 

Chances are you know that already.

 

This is not good since many customer IT installations in industry require still IE as part of the infrastructure.

 

Best Regards

Stefan

 

From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Dienstag, 13. September 2016 00:52
To: public-aria@w3.org <mailto:public-aria@w3.org> 
Subject: Minutes for Monday, 12 September 2016 ARIA Authoring Practices Guide Task Force

 

Brief minutes can be found here

http://www.w3.org/2016/09/12-aria-apg-minutes.html

 

On 9/9/2016 6:24 PM, Matt King wrote:

Monday, 12 September 2016  ARIA Authoring Practices Guide Task Force 
Time: 10:00 AM US Pacific, 1:00 PM US Eastern 
duration: 1.5 hours
IRC server: irc.w3.org, port: 6665, channel: #aria-apg 
 
------------------------------------------------------- 
To join the WebEx audio conference, you may call in via phone or join the online meeting and request a call back to any number.
US toll call-in: +1-617-324-0000
Access code (meeting number): 646 444 732 
Mobile Auto Dial:+1-617-324-0000,,,646444732#
To join the online meeting:
1. Go to https://mit.webex.com/mit/j.php?MTID=m4b54b847795d432ef8a2ba82e488fea2
2. Enter your name and email address. 
3. Enter the meeting password. You may ask for it on the IRC channel if you do not know it.
4. Click "Join". 
Add this meeting to your calendar: https://mit.webex.com/mit/j.php?MTID=m5a5104a880dad8d62ca1f36f5dbf90c1 
To view in other time zones or languages: https://mit.webex.com/mit/j.php?MTID=md6ec306a8bf0e87696e63103d9c6c4bd 
 
------------------------------------------------------- 
agenda: 
Agenda+ Issue #12: code review guide (Ian) https://github.com/w3c/aria-practices/issues/12
Agenda+ Issue #54: Draft Alert Dialog or Message Dialog design pattern (Matt) https://github.com/w3c/aria-practices/issues/54
Agenda+ Issue 67: Develop example Accordion (CSS changes by  James) https://github.com/w3c/aria-practices/issues/67
Agenda+ issue 104: Develop examples of data grids using the grid design pattern https://github.com/w3c/aria-practices/issues/104
Agenda+ Issue 109: Develop example of the tree view design pattern (Jon/Jemma) https://github.com/w3c/aria-practices/issues/109
Agenda+ Issue 110: Develop example of menu or menubar design pattern (Jon/Jemma) https://github.com/w3c/aria-practices/issues/110
Agenda+ Review status of current example development work https://github.com/w3c/aria-practices/wiki/Design-Patterns-Status
Agenda+ Review state of milestone plan https://github.com/w3c/aria-practices/milestones?state=open
 
-------------------------------------------------------- 
Resources: 
Previous meeting: https://www.w3.org/2016/08/29-aria-apg-minutes.html
Git Issues: https://github.com/w3c/aria-practices/issues
Defects open in bugzilla: https://www.w3.org/Bugs/Public/buglist.cgi?component=Practices <https://www.w3.org/Bugs/Public/buglist.cgi?component=Practices&list_id=45642&product=ARIA&resolution=> &list_id=45642&product=ARIA&resolution=--- 
APG editor's draft: http://w3c.github.io/aria-practices/
APG master in rawGit: https://rawgit.com/w3c/aria-practices/master/aria-practices.html
APG 1.1 public working draft: http://www.w3.org/TR/wai-aria-practices-1.1/
 
------------------------------------------------------- 
WebEx support:
1. Go to https://mit.webex.com/mit/mc 
2. From the left navigation bar, choose "Support".
 
 

 

-- 
Regards, James 

 <http://www.oracle.com> 
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781>  | Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918>  | Video: james.nurthen@oracle.com <sip:james.nurthen@oracle.com>  
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment