I'm having a hard time getting a footnote in a table header to be read by a screen reader. I'm fairly new to tag structuring and such (and using Adobe Supposrt Community). I feel like I have the structure right, but I get a bit confused on where some of it needs to be (in the reading order). My first attempt the reader only read the note number, then it would say blank, and now it says nothing when read.
The footnote appears in the 1st row column header (the table header spans 2 rows, and is a repeating header.) I have fixed the table so it is seen as one whole, and the refference appears physically at the bottom of each page, but I only have it tagged on the 1st one (of 3 pages).
This Note is at the end of the table, structure-wise. From what I am reading, it can/should be moved to be after the reference in the reading order? When I do that, it breaks the table, since the tag needs to be in the root level of the doc. Is this all correct? Is there an actual way to do this? The table was created in InDesign, and used a cross-ref style and we run our PDFs through CommonLook PDF for remediation, if that helps. Thank you to anyone who can help shed some light on what I'm doing.
This is a very difficult situation to resolve. First, footnotes in tables are tough to control in any part of a table because they interrupt the reading order of the tables matrix of rows and columnns. That matrix concept is critical for users of screen readers to understand where they are in the table; in which column and in which row.
Footnotes themselves (not just table footnotes) are loosely defined in the PDF/UA standards, so there isn't much guidance on how to best handle them.
Our studio's policy is to hyperlink the footnote's citation (superscript 1 in the text) to its corresponding note at the bottom of the table. Use InDesign's hyperlinks panel to set the destination anchor, and then hyperlink to it. Also put Alt Text on the hyperlink that says "Footnote 1." This method has these benefits:
Let's the user know that there is a footnote.
Let's the user decide if they want to hear the contents of the footnote. They can choose to click and go to the footnote, or skip it, which they're likely to do when they are reading that heading for the umpteenth time.
Which brings up one concern I have with footnotes in table header cells <TH>.
By default, a screen reader voices the information in the data cell's <TH> first, and then the actual data in data cell. You can imagine how often the user will hear about footnote one and they read down that particular column (two columns in your example). It'll drive the user nuts!
I think your table needs a redesign to be fully accessible and functional for the greatest number of people, sighted or not. Some suggestions:
Get the footnote out of the table header. Instead, the particular content in your example could be placed before the table <Table> itself as a <P> body text paragraph. Something like "Note: Kaiser Foundation Healthcare NW, etc." This is critical information for all users, and when we bury it in footnotes at the bottom of a table, it nearly never gets read by those using assistive technologies, especially screen readers. The table itself is just too difficult for them to even get to the footnotes at all. So we try to find creative ways to put that info as body text before the user even starts to navigate the <Table> at all. This strategy doesn't work for all tables, but I think it can in your example.
You have merged cells in the body of the table, which become really difficult for screen reader users to navigate and perceive. The table becomes confusing to screen reader users. We recommend breaking apart those merged cells so that they again correspond to each individual column. The "Classic" column needs its "no" symbol, and so does the "DCHP" column.
Put Actual Text on each symbol (yes, each and every one). "Yes" for the black checkmark, "No" for the green symbol.
Hey Bevi, Thank you very much for this great explanation. Your reply may be of some help for us designers to leverage our writers/program people to remove footnotes from tables (and simplify even more). We understand how difficult it is for tables to be accessible-hence my struggle, I didn't know if it would be completely possible not knowing the limitations. Ultimately it is the meeting the needs of and ease of use for the user we are looking to (as designers) maximize.
These benefits tables were our compromise to the carriers and programs who wanted to include everything and the kitchen sink-some footnotes in our other, older tables were actual language in the data cells, repeated over and over which may have been more accessible, but made the tables huge and use even more paper in printings. And, like you said, repetitive. Using a hyperlink as a header footnote will certainly help, but hopefully we can get our programs and writers to rethink their approach. We do have the actual text applied to the symbols in the cells - these are Fontawesome ligature icons, so the screen reader was reading the actual typed words ("ban" for unavailable and "circle-check" for available). And thank you for the reminder to review the contrast on the icons also!
Thank you again, for helping out with this puzzle and enlightening me on these aspects of accessibility, I am grateful.