RE: Core AAM + Authoring: Should the "log" role applied to a table element still be presented as a table?

Personally I don't see how you can do this without opening up the argument that if this is done here then it should be done on all roles equally. E.G What if it was role="region", or role="dialog", or many other roles that may be valid in context when applied. Also what about lists like UL, OL, and DL where the same issue applies?

There has been a long standing issue where role="presentation" and role="none" explicitly state in the spec that child element roles within structural HTML elements will be nullified by the browser, but this has never been true for any other role applied to the same element.

As a result, if you apply a different role to something like a table as mentioned above, or a list element, but no other roles directly to the child nodes of the same structure, these child nodes become orphaned in the accessibility tree and only become discoverable as issues when encountered by ATs.

So I see this proposal as a partial way of addressing this, however it doesn't account for instances when the author is actually trying to suppress the native element structure in order to provide some specific type of implementation for the user.

The way I've been dealing with this when teaching developers, is to say that adding any role other than presentation or none to a markup structure like table or one of the list elements, will change the role of that element so that it does not match the native HTML structure. So to preserve this, add a surrounding HTML div element and add your role to that instead which will then convey the unmodified markup structure within it.

One danger with only doing something like this with role=log, is that developers are likely to see it as a browser bug if it does not do this elsewhere in all cases, or that this by itself is a bug because it does not match the spec.

I'm not sure what the right answer is here, because this seems simple on the surface but may not be when applied elsewhere.


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Tuesday, August 01, 2017 4:18 AM
To: ARIA Working Group <public-aria@w3.org>
Subject: Core AAM + Authoring: Should the "log" role applied to a table element still be presented as a table?

Thread bump. I sent this a month and a half ago, but got no reply.
https://lists.w3.org/Archives/Public/public-aria/2017Jun/0031.html


I've modified the subject with the "Core AAM + Authoring" prefix because if the answer is that the table nature needs to be preserved, that is not reflected in the Core AAM and thus might not actually happen in implementations. And regardless of the answer, this seems to have implications for authoring practices: Authors should (I assume) want to know if the table nature is expected to be preserved or not when they use the log role.

Thanks in advance for your feedback on this matter. Original post follows.

--------------

Hey guys.

I was looking at the mappings for the "log" role in the Core AAM:
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#role-map-log


MSAA/IA2 is the only platform which does not map the ARIA "log" role to a specific platform accessibility API role. The potential implication of this is that applying the "log" role to a table may cause that table to stop being presented as a table by ATs (with the exception of MSAA/IA2).

As a test, I used the following in Safari:

    <table border="1">
        <tr><th>log</th></tr>
        <tr><td>foo</td></tr>
    </table>

That, as one would expect, is exposed as an AXTable, with table properties (e.g., number of rows and number of columns) and a table hierarchy (row children with cells, column children with cells).

But if you add the log role to that very same test case, the role becomes AXGroup with a subrole of AXApplicationLog. The table properties, not surprisingly, go away. Ditto for the table hierarchy.

I don't know UIA works, but there's nothing in the Core AAM that says a log should implement the table pattern if the log role is applied to a table element. I also don't know what would happen to the table-related descendants (can you have TableItem control type children in a Group control type object?)

In the Gecko bug I filed for my platform [1], Alex Surkov pointed this issue out. And I asked if this could be resolved by implementing the table interface on role log if the underlying element is a table. This would allow Orca to provide table navigation commands within a log.
While I continue to think this is doable (though with some potential quirks), there's nothing in the Core AAM that says it should be done.
And it's not currently being done in WebKitGtk which, like Safari, considers a log to not be a table.

Even if I do implement AtkTable for logs that are tables, and tables that are logs continue to be tables in IA2, the fact that they become groups in UIA and AX API means the user experience will vary widely. And isn't that the very thing we're trying to avoid?

So like I asked in the subject, should the "log" role applied to a table element still be presented as a table? If the answer is "no", then it's all good and thank you for your time. :) But if the answer is "yes," I believe that won't happen without some changes to the Core AAM.

Thoughts?
--joanie

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1305446

Received on Tuesday, 1 August 2017 16:55:45 UTC