Accessibility FAQ

SuperTables has a mode for enhanced accessibility and Using enhanced accessibility mode, all rows and columns will be rendered in DOM, even the rows and columns which are not visible on the screen. Following are the questions you might get if you use tools like axe dev tools to assess the accessibility of SuperTables.

Why does my page not have a level one heading?

ARIA Rule : Page must contain a level-one heading

Generally, it is a best practice to ensure that the beginning of a page’s main content starts with an h1 element, and to ensure that the page contains only one h1 element. However, ARIA Standards also mention that in the case of iframes, the heading can be an <h2> or <h3> so we have added an invisible heading, which tells the screen readers that it is the SuperTables container.

Why certain elements do not have an ARIA parent role?

ARIA Rule: For every column header ARIA parent role must be added.

By default, SuperTables has a column header’s role described as role=”columnheader” - element containing a column header. For all the member cells there is an ARIA-Describe By tag which explains where it belongs.

However, even though all aria tags have been applied to the necessary elements, some screen readers have trouble navigating the tags when the grid structure gets more complex (eg. grouped columns). This is the reason why there are some limitations in announcing the correct column names.

I cannot find the landmarks for some elements?

Aria Rule: landmarks to element

Navigating a web page is far simpler for screen reader users if the content splits between multiple high-level sections. Content outside of sections is difficult to find and the content’s purpose may be unclear. However, in this case, SuperTables stand as one single element instead of website where contents are spread of multiple sections.

All elements in SuperTables have a role attribute which describes what it is, see the image below.

Does the SuperTables element in the screen have an identifier?

ARIA Rule: A Main landmark should be available in the SuperTables structure

Screen reader users can use keyboard shortcuts to navigate directly to the first h1, which, in principle, should allow them to jump directly to the main content of the web page. If there is no h1 or if the h1 appears somewhere other than at the start of the main content, screen reader users must listen to more of the web page to understand its structure, wasting valuable time. To tackle this issue we have added an invisible heading which will help the screen reader to easily recognize the SuperTables container.

How do I optimize SuperTables for accessibility?

ARIA Rule: configuration option to enable/disable Accessibility optimization for the grid

You can use the “Enhanced accessibility option” if you wish to optimize SuperTables for accessibility. It in general disables the column and row virtualization. This as result generates all cells in the DOM thereby you will see a considerable reduction in performance.

There may be 2 scenarios when you may wish to disable column virtualization (if you prefer).

1) Auto-sizing of all columns. This will ensure that all columns, and not just the columns which are rendered on the screen, will be resized.

2) Support for a11y. This is to prevent any potential issues with keyboard navigation and screen readers (https://www.a11yproject.com/).

Accessibility audit shows missing ‘Main roles’ which helps users to skip sections.

Aria Rule: Bypass repeated blocks by setting the role to “Main”

Since websites often display secondary, repeated content on multiple pages (such as navigation links, heading graphics, and advertising frames), keyboard-only users benefit from faster, more direct access to the primary content on a page. This reduces keystrokes and minimizes associated physical pain. Since SuperTables is just one page and there are navigation shortcuts to move around. This does not affect the accessibility of SuperTables.

Are there other general limitations to accessibility in SuperTables?

Navigation to pinned rows/columns

Screen readers assume that the visual and DOM element order are identical. Specifically, when you pin a row/column, it causes elements to be rendered in different containers. This is why you cannot use screen readers to navigate into pinned row/column cells, as in fact, this means they’re rendered in a different element from the rest of the columns/rows which are scrollable.

Limitations announcing the correct column name in grouped columns

Even though all aria tags have been applied to the necessary elements, some screen readers have trouble navigating the tags when the grid structure gets more complex (eg. grouped columns). This is the reason why there are some limitations in announcing the correct column names.

No announcements of state change of a grid cell or grid header

Some screen readers will not recognize changes that happen to an element that is currently focused (including children of this element). So in order to detect changes (eg. sorted state, updated labels, etc…), you will need to move focus to another element and back.