IBM Equal Access Accessibility Checker violations

[luisrudge]

When running a page with a table through this checked, it highlights the following issue:

Violation
An explicit ARIA 'role' is not valid for element within an ARIA role 'grid' per the ARIA in HTML specification
Table structure elements cannot specify an explicit 'role' within table containers

Specifically, this happens because all the elements inside a table have a row, but this tool seems to think that this is invalid based on aria rules. Links provided by the checker:

https://www.ibm.com/able/requirements/requirements/#4_1_2
https://www.w3.org/TR/wai-aria-1.2/

Any thoughts on this?

[snowystinger]

@majornista

[majornista]

It seems this tool is validating against the ARIA in HTML specification: https://www.w3.org/TR/html-aria/#avoid-specifying-redundant-roles

3.2 Avoid specifying redundant roles

The following example illustrates a button element which has also been provided an explicit role=button. Specifying this role is unnecessary, as a "button" element is already exposed with an implicit button role. In practice this particular instance of redundancy will likely not have unforeseen side effects, other than unnecessarily making the markup more verbose, and incorrectly signaling to other authors that this practice is useful. Please review the section 3.3 Be cautious of side effects for an example of where specifying unnecessary roles can be problematic.

Example 4: Redundant role on button

<!-- Avoid doing this! -->
<button role="button">...</button>

Similarly, the following uses a role=group on a fieldset element, and a role=Main on a main element. This is unnecessary, because the fieldset element is implicitly exposed as a role=group, as is the main element implicitly exposed as a role=main. Again, in practice this will likely not have any unforeseen side effects to users of assistive technology, as long as the declaration of the role value uses ASCII lowercase. Please see 4.4 Case requirements for ARIA role, state and property attributes for more information.

Example 5: Redundant role on fieldset and main

<!-- Avoid doing this! -->
<fieldset role="group">...</fieldset>
<!-- or this! -->
<main role="Main">...</main>

The following uses a role=list on an ul element. As the ul element has an implicit role of list, explicitly adding the role would generally be considered redundant. However, some user agents suppress a list's implicit ARIA semantics if the list markers are removed from the visual presentation of the list items. Generally the redundant declaration of an element's implicit role would not be recommended, but in specific situations such as this, and where the role is necessary to expose, authors can explicitly add the role.

Example 6: Redundant role on list

<!-- Generally avoid doing this! -->
<ul role="list">...</ul>

I checked with @jnurthen and we are in agreement that the IBM checker may be overstepping here by making a best practice recommendation a requirement.

Redundant, yet correct, aria roles have no perceivable effect on the behavior of assistive technologies.

I’m also a bit worried about the behavior when the table DOM structure is altered with virtualization.

That being said, we may be able to determine the implicit role of the element that the useGridRow hook returns, because it accepts a ref for the element as a parameter:

react-spectrum/packages/@react-aria/grid/src/useGridRow.ts

Lines 42 to 84 in 369e1e7

	/**
	* Provides the behavior and accessibility implementation for a row in a grid.
	* @param props - Props for the row.
	* @param state - State of the parent grid, as returned by `useGridState`.
	*/
	export function useGridRow<T, C extends GridCollection<T>, S extends GridState<T, C>>(props: GridRowProps<T>, state: S, ref: RefObject<FocusableElement | null>): GridRowAria {
	let {
	node,
	isVirtualized,
	shouldSelectOnPressUp,
	onAction
	} = props;
	let {actions} = gridMap.get(state)!;
	let onRowAction = actions.onRowAction ? () => actions.onRowAction?.(node.key) : onAction;
	let {itemProps, ...states} = useSelectableItem({
	selectionManager: state.selectionManager,
	key: node.key,
	ref,
	isVirtualized,
	shouldSelectOnPressUp,
	onAction: onRowAction || node?.props?.onAction ? chain(node?.props?.onAction, onRowAction) : undefined,
	isDisabled: state.collection.size === 0
	});
	let isSelected = state.selectionManager.isSelected(node.key);
	let rowProps: DOMAttributes = {
	role: 'row',
	'aria-selected': state.selectionManager.selectionMode !== 'none' ? isSelected : undefined,
	'aria-disabled': states.isDisabled || undefined,
	...itemProps
	};
	if (isVirtualized) {
	rowProps['aria-rowindex'] = node.index + 1; // aria-rowindex is 1 based
	}
	return {
	rowProps,
	...states
	};
	}

So at line 70, use something like this:

      role: (ref?.current?.tagName === 'TR' ? undefined : 'row'),

[majornista]

Also, it should be noted that the ARIA in HTML document has a PR that updates its wording to explicitly allow, but not recommend, using a redundant role on table elements: https://github.com/w3c/html-aria/pull/436/files?diff=split&w=0#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R3098-R3101

[luisrudge]

Considering it's not recommended (even if allowed), what's your take on removing this from the table component?

[majornista]

I think it might be better to open an issue against the IBM tool, which is elevating the severity level unnecessarily.

[majornista]

Note that in React-Aria, we replace all tr, td, and th elements with div elements when the collection is virtualized, so we have to use aria-* for that use case.

I actually spent some time yesterday experimenting with adding these conditionals to remove redundant aria-* attributes depending on the element being rendered, but there were still cases where the IBM testing tool was being way too strict, IMO. For example, it calls the use of role="rowheader" on a td as serious failure. It also objects to the omission of a scope attribute on a th with role="colheader".

[luisrudge]

Sounds good. Thanks for the follow up!