W3C home > Mailing lists > Public > public-aria@w3.org > August 2017

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

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Tue, 1 Aug 2017 07:18:21 -0400
To: ARIA Working Group <public-aria@w3.org>
Message-ID: <25bd805e-52f9-9c45-d602-b7a4aeadd3a3@igalia.com>
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 11:18:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 August 2017 11:18:57 UTC