E-mail List Archives
Re: Turning in/off inaccessible feature
From: Mallory
Date: Sep 17, 2019 2:41AM
- Next message: Michael Ausbun: "1.4.3 & 2.4.7: evaluation while blind"
- Previous message: Praunicorn: "Re: Question on a caption for Accessible Tables withNavigation"
- Next message in Thread: None
- Previous message in Thread: glen walker: "Re: Turning in/off inaccessible feature"
- View all messages in this Thread
I've done the "sticky table header" thing in the past with 2 tables (one is aria-hidden so what sighted folks see (1 table) is what AT presents (1 table) however when those table columns are also interactive controls (sortable columns) that technique no longer works for every combination of user input.
However I recently was auditing a site where the client was doing several different types of sticky/scrolling tables and there was one they did which at least worked on desktop (I don't have any iThings so could not test mobile, although these were large dashboards which are simply nightmares on tiny mobile devices anyway).
The used a container around the table for scrolling, and used position: sticky or fixed on the thead (this was a case of the table headers being sticky rather than the first column). This seemed to work because the position attribute did not undo the table semantics (unlike changing the display attribute), though maybe also because the thead's role was kinda negligable anyway: so long as we had column headers above cells, screen readers did the Right Thing and it worked with nearly everything else (low-vision zooming is another instance where, for example, I cannot use any online Excel sheets because of excessive stickiness, and Google Sheets with anything sticky means I'm lucky to see more than 1 column at best).
A sticky row-header column may not work as nicely as an entire thead, but if it hasn't been tried, you could try it and see how it reads in AT. Otherwise the two-table thing is a pain in the butt but it has been used successfully in the past so long as the AT-hidden table does not need to be controls (re-orderable rows for example; checkboxes for selection may still work fine).
The idea of allowing users to choose whether to stick or unstick the column is excellent though, because as a browser zoomer this would benefit me greatly (sometimes I would like to see more than 1 or 2 columns at a time without sticky things stealing my limited screen real estate).
On Tue, Sep 17, 2019, at 1:06 AM, glen walker wrote:
> The "hacking" comment and using the roles was not specifying roles on
> elements that had the role already. When you specify role="presentation"
> on a table, all rows and cells lose their identities. When you're hacking
> two separate tables to appear as one table, you have to reapply the
> appropriate roles to the <tr> and <td> elements.
More like, nobody's adding role="presentation" but they are CSSing things like display: block. Unfortunately this also removes the default roles in many browsers (I'm not sure if all do this, but certainly Firefox and Safari have both done it for a very long time).
cheers
_mallory
- Next message: Michael Ausbun: "1.4.3 & 2.4.7: evaluation while blind"
- Previous message: Praunicorn: "Re: Question on a caption for Accessible Tables withNavigation"
- Next message in Thread: None
- Previous message in Thread: glen walker: "Re: Turning in/off inaccessible feature"
- View all messages in this Thread