-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TableCell should not add role="cell" if a th component is passed #21470
Comments
I agree that we just shouldn't add the role and let users fix this on their own. I would argue this for any Almost all cases I see are invalid anyway (abuses styles without semantics, inaccessible regardless etc). The original motivation in #20431 can be easily fixed with |
So this issue is now about removing the behaviour to set the role? Anyway, I've looked into it really quickly and came up with this diff --git a/packages/material-ui/src/TableCell/TableCell.js b/packages/material-ui/src/TableCell/TableCell.js
index d2d044720..6178f9b71 100644
--- a/packages/material-ui/src/TableCell/TableCell.js
+++ b/packages/material-ui/src/TableCell/TableCell.js
@@ -123,19 +123,27 @@ const TableCell = React.forwardRef(function TableCell(props, ref) {
const tablelvl2 = React.useContext(Tablelvl2Context);
const isHeadCell = tablelvl2 && tablelvl2.variant === 'head';
- let role;
let Component;
if (component) {
Component = component;
- role = isHeadCell ? 'columnheader' : 'cell';
} else {
Component = isHeadCell ? 'th' : 'td';
}
-
+
let scope = scopeProp;
if (!scope && isHeadCell) {
scope = 'col';
}
+
+ let role;
+ if (isHeadCell) {
+ role = 'columnheader';
+ } else if (scope === 'row') {
+ role = 'row';
+ } else {
+ role = 'cell';
+ }
+
const padding = paddingProp || (table && table.padding ? table.padding : 'default');
const size = sizeProp || (table && table.size ? table.size : 'medium');
const variant = variantProp || (tablelvl2 && tablelvl2.variant); |
I'd just revert #20431 and add some regression test that illustrate why the approach wasn't viable e.g. |
Hi all, I just got bitten by this issue too. I can't use @tchmnn I might be missing something but it looks like your patch generates |
The docs for a Simple Table say:
The screen reader behavior referred to in the docs is no longer working in the Simple Table example, at least not using VoiceOver.
I believe this is because the cells are now being given a role="cell".
#20475 introduced the concept of a default role when passing a component to the TableCell via props. It definitely makes sense to add a role for accessibility when passing custom components, but probably not in cases where the component we are passing has native roles already (like a "th" tag)?
If that's not possible, as a user I'd at least like to have some sort of override, by passing a role directly or some other prop flag perhaps.
Current Behavior 😯
The following:
Renders:
Expected Behavior 🤔
Should render:
Steps to Reproduce 🕹
Simple Table documentation can be used to verify the issue
Context 🔦
I'm using a nearly identical approach in my application, and after upgrading to v4.10.1 I have failing unit tests because cells that used to be recognized by their "rowheader" role are no longer recognized. Screen reader behavior that reads row titles when navigating the table is also broken in my application.
Your Environment 🌎
The text was updated successfully, but these errors were encountered: