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

It would seem weirdly inconsistent if <table role="log"> resulted in a new thingy exposed as a "log table" or something like that. ARIA roles override native semantics so why make an exception for log? Such exceptions add complexity.

If an author wants to make a log table use <div role="log"><table></table></log>.

I'd be happier if we didn't have the log, alert, and alertdialog roles. It seems they confuse event behaviors with semantic structures. But, as long as we have them, unless we are going to separate them out into a separate branch of the ontology and make a special set of rules for them, they should be processed in a manner consistent with the rest of the spec.

Matt

From: Joanmarie Diggs [mailto:jdiggs@igalia.com] 
Sent: Tuesday, August 1, 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 22:07:27 UTC