Run schedule semantics

[Vuurvos1]

Is there any good reason the run schedule table is built out of a ton of divs with a CSS grid? I feel like an HTML table would be a better semantic fit and could make the styling of the run schedule a lot easier since the table would do most of the layout for you instead of relying fully on CSS. I know this is a fairly minor thing but still would love an opinion on this. If an HTML table were to be a better fit, I would be more than happy to convert the run schedule to a table in the v2 app.

[duncte123]

Tables are not responsive enough, you can see this for yourself on v1.

The only reason we would consider switching back to a table is if this current solution does not work well enough with a screen reader

[Vuurvos1]

Since divs have no semantic meaning, CSS grid is only visual and doesn't change the way a document is structured I can only imagine it would be quite hard to navigate the current schedules using something like a screen reader since the table would be read fully sequentially. If you would use a table the screen reader would have a lot more context about the column/row you are currently in. Navigation should also be easier since you can move left/right/up/down from the cell you are currently in.

I tried setting up Oengus v1 but wasn't able to view the schedule (I managed to start the project but couldn't find the schedule table on the local site) so maybe I'm missing something but I made a quick table demo on Stackblitz: stackblitz.com/edit/svelte-a3tquv. Using some CSS media queries the table seemed responsive enough.

Sources:

• https://www.colorado.edu/digital-accessibility/2016/09/17/when-use-tables-and-how-make-them-accessible-screen-reader-users
• https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/CSS_Grid_Layout_and_Accessibility
• https://youtu.be/X1KR4u94cho

[duncte123]

I tried setting up Oengus v1 but wasn't able to view the schedule (I managed to start the project but couldn't find the schedule table on the local site) so maybe I'm missing something

That is exactly what https://sandbox.oengus.io is for

[BobChao87]

I've tested screen readers pretty thoroughly with that page because I was quite concerned about it. The only thing they really lack is communicating that rows can be expanded, but it's not like an actual table would be better at that, that's up to the individual cell either way.

The way the grid is semantically structured should allow for a level of positional awareness, even when navigating solely via a screen reader. That said, I'm not blind, and while I have tested it, I cannot experience it in the same way that someone efficient with these tools would be able to.

We can actually add WAI-ARIA table roles to any markup to make it report the data as a table to screen readers, so there's no need to make the HTML into the less flexible and, frankly, regularly frustrating HTMLTableElement. I simply haven't gotten around to it yet, partially because I know it at least works well enough as-is.

If that's something you'd like to contribute to Oengus, please feel free! You can find a starter bit of documentation for the WAI-ARIA table attributes here. If WAI-ARIA tables aren't good enough compared to native tables for some reason, please feel free to expound upon that here or link us to some resources, I'd love to learn more about that. As far as I can tell, the main difference for screen readers is that HTMLTableElements just automatically provide the WAI-ARIA table roles by default.