非标准表格数据的可访问性方法

Question

Issue Description:

I am developing the UI for a list of advisor meetings. The list is formatted like a table, with a row of column headers and corresponding data. Each meeting contains a row of data as well as a description section below that row. Each meeting card is also expandable to show additional data. I am unsure of the best aria method to make this markup more accessible.

Screenshot of the UI I'm developing (actually a gif that shows the expand functionality)

Goal:

To make it easier for screen readers to easily navigate the list of meetings

Potential Solutions:

1. Use aria attributes to construct a table for the elements that are in a table format ( https://www.w3.org/TR/wai-aria-practices-1.1/examples/table/table.html ) I'm not sure how navigable this would be, especially when it comes to navigating to the description section or the collapsible details section...
2. Hide the table header from screen readers and make the meeting wrappers li elements so that it forms a list. I would add hidden screen reader labels to each of the unlabeled values. My concern is that the entire meeting is too much content for a li element and I'm not sure what the navigability for screen readers would be like.

I am certainly not an accessibility expert so I'm hoping that someone with more experience than me can point me towards the best practice / best implementation for a case like this. Any suggestions would be much appreciated.

Answer 1

From my own research for work, I have come up with the following pointers:

• use the most specific and accurate html tag, and use css to style it the way you want (no need to make a button out of a span, a button's default styles can be overwritten)
• use case as much as possible to reduce unnecessarily nested html
• aria attributes are great, but should be a last resort.

In the case of your table, I would say use the standard html table elements, just make sure to use the correct tags, like th , and make sure to include a description or label at the top of the table. Screen readers should know what to do with a table. If a table is the most accurate description of what you're building, use that :) Just be sure to use it in a standard and predictable way, and (see how often I say this) use only css for your styling.

For the meetings there is an element for that: https://www.google.com/amp/s/www.geeksforgeeks.org/html5-details-tag/amp/ you can style it any way you want, but I think the arrow is chosen by the browser. But a screen readers will read the summary and give the user the option to open it. I think yours is a great use case for this element.

I wouldn't hide content like headers from screen readers. People who use assistive technologies are used to navigating with them and headers are informative content.

Kudos for considering accessibility in your code :)

Answer 2

Tables for Structure

I would recommend staying away from tables, but that's my personal preference. You could make this accessible using tables, but it would end up being more complicated than it needs to be.

List Structure

The list structure that you described would be fine, but ultimately you could convey the hierarchical structure of what you're doing here by using only headings and paragraphs.

Off-the-Shelf Solutions

Many of the popular frontend frameworks (like Bootstrap, Material, etc.) have already solved the problem of accessible accordions , collapse elements , expansion panels , or whatever else you want to call it. Unless you're a strong JS developer, I would recommend starting with a pre-made solution from a well known framework and then testing using a decent screen reader .

Custom Solutions

There's nothing wrong with implementing your own solution, assuming you have the skillset and time available to do so.

W3C has some great guidance on the desired behavior of accessible accordion elements , and the A11Y project has a nice design pattern library with usable code samples.

For the ARIA markup, you'll need to make use of aria-expanded , aria-controls and aria-labelledby respectively. Depending on how your screen reader tests go, you may also wish to set focus when the expandable element opens.