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

Hi Matt,

Many thanks for your detailed answers. Als always, I’d like to comment to some of them.

>>> Try with IE 11 now.…. That said, we will make some effort to offer an implementation of each ARIA feature that functions in the latest IE.
>>> The main reason for doing that is to provide screen reader developers with at least a minimal level of IE interoperability testing for each ARIA feature…

It works now also with IE11. Good fix! Please be aware that not only AT guys will need the examples for interoperability testing. We do testing with self-written tools and tools like MSInspect, too, since we like to know what we can expect from platform API mapping, and I bet we are not alone here in universe.

As an additional enhancement, I would propose to make use of the CSS outline property for better visual focus rectangle rendering. The default system focus for grid cells can barely be seen on some browsers (IE,FF). This effects all examples not just the grid examples. You can provide e.g. a checkbox on top of page or an URL flag  to activate this. You can even make this browser-dependant since I think Chrome does it already fine by default.

>>> 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.

This is exactly the problem. AccessibleName is *not* enough. This was a major design flaw in ARIA 1.0. AccessibleRoles, States and Values must also be communicated. I explain you why:
When x/y navigation with arrow keys happens, and focus is on the *cell*. user needs to have the following information for selected rows/ cells containing e.g. combo boxes with values, states. additional tooltips and/or additional hidden associated info (such as error or warning states/messages)

[row 1] – [column “Car Parts”] – [combo box] -  [tyres] – [error: Tyres are not selectable for this particular business partner] – [Tooltip Info: please be informed that not all parts are allowed/available for certain business partners]

What we get currently (browser/screen reader dependant, and not necessarily in this exact sequence) when focusing the cell is just

[row 1] - [column “Car Parts” ] -  [selected] – (and maybe, dependant of UA/AT desparate mapping fallbacks “tyres”]

How should anyone on earth know that something is wrong with the value of a combo box inside when traversing X/Y with arrow keys and not getting all this info? User doesn’t even know about the role of the content for he can prepare himself for subsequent operation, such as pressing ALT+Arrow Down to open it directly, if supported, or pressing F2 to enter. User just don’t *know*.

I could give other problematic examples (sliders, rating indicators, numeric spinners etc) but even for simple buttons in cells not all implementations report relliably the role inside, and consequently, user does not know what to do.

To bypass all this it *was* necessary to write glue code to give the end user a better navigation experience using the ARIA 1.0 grid navigation pattern and binding simple activation actions like click and check on cell level.  This was not a superfluous or “if you like” effort, it was *mandatory*.

Let’s have a look to the ARIA 1.1 proposal then. I’m looking forward that with this approach the situation will get better. One problem with this approach I have is: How do you select individual active cells when focusing only the inner element and never the cell? With ARIA 1.0 this was a no-brainer. Chances are that you have to invent a separate hot key for this in ARIA 1.1.


>>> 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.

One final comment regarding 1.0 vs. 1.1 in the grid examples. I think it should be clearly separated between the two approaches in the examples.

The current examples are a mashup of both. I explain you why. When focus moves between cells of grids with static text and interactive elements it is irregularily on cell level rendered when text is inside, and it is rendered inside the cell containing active/editable elements. As result, the focus “pumps” between cells.

Imagine a ARIA 1.1 plain text grid. Focus should always be directly around plain text content and NOT on the cells. This would be straight, for adding things like buttons afterwards will focus also cell content.

In my opinion, focus should be in ARIA 1.1 ONLY on cell level when the cell itself is interactive. You can argument that having the focus on the cells is a sign for non-interactive content but then you need to forbid interactive cells. Some headers in the examples are not so, this is confusing.

Best Regards
Stefan






From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Mittwoch, 14. September 2016 00:34
To: Schnabel, Stefan <stefan.schnabel@sap.com>; 'James Nurthen' <james.nurthen@oracle.com>; public-aria@w3.org
Subject: 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<mailto: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<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

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&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

[Oracle]<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
[Green              Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment