Forum Stats

  • 3,836,977 Users
  • 2,262,211 Discussions
  • 7,900,163 Comments

Discussions

Issues with Accessibility Features of OJ Table

DaveArch
DaveArch Member Posts: 125 Red Ribbon

JET Version 10.x

Hi Community

We have some clients with a large number of users who have accessibility needs. We are finding that, whilst most of the OJ components have good support for accessibility, the OJ Table component uses techniques which causing issues for keyboard-only and screen reader users.

Specifically, there are 3 main issues:


1) Focusable elements within a row don't receive focus in the order a user would expect and require the custom interaction via the F2 key:

Where navigation links are contained within a row, a user must hit F2 to navigate into the row before being able to select the links. The same is true for editable tables where the F2 key is needed to access the row. Most keyboard-only users are not used to this pattern and instead expect tables to be navigable via the Left and Right keyboard keys once a row is selected as explained here.  For screen-reader users, this is even harder as the table does not announce how to navigate so users have no idea of how to interact with the table.

 https://www.oracle.com/webfolder/technetwork/jet/jetCookbook.html?component=table&demo=actionTable

https://www.oracle.com/webfolder/technetwork/jet/jetCookbook.html?component=table&demo=editableFormTable


2) Tables are not marked up as tables or the structure of the table is not programmatically implemented.

This is because the ARIA ‘application’ role specified on the table tag removes any table semantics.

<table data-oj-internal="" class="oj-table-element oj-component-initnode" role="application" tabindex="0" aria-labelledby="nd-11908-t" x-ms-format-detection="none">

This means that a screen reader user will not understand the structural makeup of the table as well as relations in the data. 

A screen reader uses the programmatic implementation to convey structure and layout, without this a screen reader user will not know how a table is structured, or even if there is a table. A screen reader also uses this programmatic implementation to present to the user via a way of screen reader key combinations, a way to navigate the data by column, rows and cells. Because they can't use these navigation mechanisms, a screen reader user must use arrow keys to read through content in a sequential manner and as required to read each bit of content in order.


3) It appears that some table functionality, such as resizing is not available via keyboard navigation, only using a mouse.

Is anyone from the JET product team able to comment on the above?

Many thanks

Best Answer

  • John 'JB' Brock-Oracle
    John 'JB' Brock-Oracle Posts: 2,807 Employee
    Answer ✓

    Hi Dave,

    Really sorry for the long delayed reply.

    Yes, the JET table component is not an aria table role. It is far to complex to meet the definition of what Aria considers a table. Up until the most recent release of JAWS, they also could not deal with the complexity of what we do in the table and that was one of the reasons for changing the role from table to application back in JET v9.

    We do understand how this can be confusing to screenreader users when they hit "T" and it says there aren't any tables, but then they tab down and hit a "table". The keyboard interaction with that table is fully functional thought, using arrow and tab keys. It does not use the JAWS table mode however. There was a bug fix in the latest JAWS release (may 2022) that could possibly let us move the oj-table component to a "Grid" role in the future, but it will never go back to a "Table" role.

    We are looking at the possibility of introducing a lite table that would function as an aria table role for use cases that do not need all of the inline editing, frozen column, drag and drop, etc.

    As for the F2 functionality. This is consistent across all of our collection components and is based on a similar use of F2 in Microsoft Excel. Since the table is a single tab stop, and arrow keys are used to move up and down through rows, there needs to be another keystroke to interact with any components that are placed inside of a row and need focus. The use of F2 has been there for almost 8 years now, and it documented in the JET Keyboard and Gesture documentation. We are looking at ways to make this more clear at the runtime level though.

    If you are working with Editable rows, there have been some accessibility updates provided in JET v12.0.4 that fix quite a few issues when using editable components placed into readonly mode inside of a table row.

    I hope this helps ,


    --jb

Answers

  • John 'JB' Brock-Oracle
    John 'JB' Brock-Oracle Posts: 2,807 Employee
    Answer ✓

    Hi Dave,

    Really sorry for the long delayed reply.

    Yes, the JET table component is not an aria table role. It is far to complex to meet the definition of what Aria considers a table. Up until the most recent release of JAWS, they also could not deal with the complexity of what we do in the table and that was one of the reasons for changing the role from table to application back in JET v9.

    We do understand how this can be confusing to screenreader users when they hit "T" and it says there aren't any tables, but then they tab down and hit a "table". The keyboard interaction with that table is fully functional thought, using arrow and tab keys. It does not use the JAWS table mode however. There was a bug fix in the latest JAWS release (may 2022) that could possibly let us move the oj-table component to a "Grid" role in the future, but it will never go back to a "Table" role.

    We are looking at the possibility of introducing a lite table that would function as an aria table role for use cases that do not need all of the inline editing, frozen column, drag and drop, etc.

    As for the F2 functionality. This is consistent across all of our collection components and is based on a similar use of F2 in Microsoft Excel. Since the table is a single tab stop, and arrow keys are used to move up and down through rows, there needs to be another keystroke to interact with any components that are placed inside of a row and need focus. The use of F2 has been there for almost 8 years now, and it documented in the JET Keyboard and Gesture documentation. We are looking at ways to make this more clear at the runtime level though.

    If you are working with Editable rows, there have been some accessibility updates provided in JET v12.0.4 that fix quite a few issues when using editable components placed into readonly mode inside of a table row.

    I hope this helps ,


    --jb

  • DaveArch
    DaveArch Member Posts: 125 Red Ribbon

    Hi JB

    Thanks for the detailed explanation, much appreciated.

    It's good to get the background as to why the table component has been implemented as it has and also good to hear that improvements are in the roadmap.

    For now, we are looking to introduce help and other features within the applications themselves to make it clearer to users what they need to do.