WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Inaccessible table

for

From: Birkir R. Gunnarsson
Date: May 24, 2023 8:50PM

Agreed, hiding the table is not ideal, perhaps put it in a region
element with aria-label="table" and have a comment right above it
pointing to the PDF as an alternative. Then the inaccessible table
boundreis are clear on the page and the screen reader user can jump
past it if they want.
And, yes, if the table is dynamic or if the ddata ever changes, the
alternative must be updated to match, which is problematic for
maintenance and ensuring equitable experience for all users.


On 5/24/23, glen walker < <EMAIL REMOVED> > wrote:
> It sounds like the HTML "table" is just a series of divs/spans with no real
> table related roles and that keyboard event handlers are allowing the arrow
> keys to navigate.
>
> In general, it's much easier to make an HTML table accessible than it is to
> make a PDF table accessible. The PDF is typically generated from another
> file (Word doc, design doc, etc) but those other files typically have
> minimal support for creating accessible content so you often have to
> manually remediate the PDF to make it accessible. If any contents of the
> table have to change, you have to do that process all over.
>
> I understand your html table comes from a third party vendor and you don't
> have control over changing it but speaking as a developer myself, there are
> sometimes ways to work around that. First you have to check the
> documentation of the component carefully because there might be ways of
> improving its accessibility. Sometimes I have been able to "post-process"
> the generated HTML code and could inject ARIA into the generated code. It
> wasn't ideal, but it helped.
>
> Your main question was "is it good enough to have an accessible
> alternative?". Yes, it's "good enough" to pass WCAG but that's only if
> your main concern is passing a minimal baseline.
> > > > >


--
Work hard. Have fun. Make history.