-
Hello, |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Hi @sang-yeo Will you share an example or two of an expandable data table? Thanks. |
Beta Was this translation helpful? Give feedback.
-
Hi @sang-yeo TL;DR; We will not be creating an expandable table that could be used to replicate what is commonly used in Console as these are inaccessible. We do have a Treegrid on the roadmap, but it does behave differently to what you may be used to and won't be a direct one for one replacement. The way the current expanding tables work in Console, and from what I've seen in SendGrid and possibly Flex mocks too, are not able to be made accessible and we will be moving away from them. What makes these tables inaccessible?Tables are a challenge for screen reader users to navigate. Unless they have appropriate column and row headers, it's very easy to get lost in a table and not understand the information you are viewing. Often, the meaning of information in a table is derived by being able to see what column and what row that data belongs to. If you lose a header and/or the row, not only can the meaning can be lost but also the relationship it has to other content in table can be lost too. Content can appear as just floating, isolated from context, relationships or meaning. In the screenshot below, the string I highlight is a SID that occurred on a certain date, from a certain number. You know that because of the column and row headers. The relationship infers the meaning. Without the column headers and rows, it's just a string, hanging out on it's own. So how does that relate to an expanding table? Well, when you expand a new row within most of the tables within Twilio products, the new row often doesn't reflect the table structure it is in. See below: The expanded row I've highlighted bares no relation to the column header structure of the table. Because it's also an entirely new row, it also is programmatically unrelated to the row that triggered it. It's isolated content, hanging out on its own. The context and as such, meaning of the content is lost to a user of assistive technology. Even if the newly expanded content was embedded in the same row, you'd likely need to use a nested table, which poses an extra layer of difficulty in communicating the meaning and relationship of the new content has to the parent table structure. As a result we will not be shipping an expandable table. What is an accessible alternative?Something that is on our roadmap is a UI widget called a Treegrid; W3C definition. All it is, is a grid (or table for namings sake) that can have expanding rows (I know, it sounds exactly like what you're asking for) that follows a hierarchy. The kicker is, to keep it a single grid the expanding row must follow the same grid structure that it is already contained in. The expanding row, is a directly related child to the parent row. It inherits the same features as the parent row. The expanding row isn't nested, and must reflect the same content structure. Prior art an be found in the Authoring practices guidelines, which admittedly is very dry. SLDS versionLightning version along with the interactive component example When will this come?I imagine we are quite a few months, if not quarters away from shipping a Treegrid I am afraid. What should I do in the meantime?At times like this, old experiences don't translate into new design language and componentry. Paste was never designed to be a one for one replacement. These expanding table experiences, if they can not conform to the Treegrid guidelines and structure need to be redesigned in a way that can be made accessible. I would suggest starting that process as soon as possible and coming to Office hours. There is likely a much better, more accessible way to represent this data to a user. |
Beta Was this translation helpful? Give feedback.
Hi @sang-yeo
TL;DR; We will not be creating an expandable table that could be used to replicate what is commonly used in Console as these are inaccessible. We do have a Treegrid on the roadmap, but it does behave differently to what you may be used to and won't be a direct one for one replacement.
The way the current expanding tables work in Console, and from what I've seen in SendGrid and possibly Flex mocks too, are not able to be made accessible and we will be moving away from them.
What makes these tables inaccessible?
Tables are a challenge for screen reader users to navigate. Unless they have appropriate column and row headers, it's very easy to get lost in a table and not understan…