- 197.1K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.7K Databases
- 221.9K General Database Discussions
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 555 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.3K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 466 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Issues with Accessibility Features of OJ Table
JET Version 10.x
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.
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?