@spaceling,

Thank you for reporting this bug left over because after specifically debugging table header display in the footnotes reference container in Atahualpa, I wan’t aware that the white color would persist, because in my instance it was black on dark gray background. So I removed the dark gray background in Footnotes containers table header cells:

.footnotes_table .footnotes_plugin_reference_row th {
	background-color: inherit !important;
}

Also needed to enforce the disappearance of the table caption through !important property and higher specificity, but missed out on the white. Sorry please.

The table header elements are required for accessibility, because else screen readers can make less sense of the table, and it must be done in HTML, not CSS or ARIA labels, as per https://a11y-101.com/development/tables recently shared in https://wordpress.org/support/topic/enhance-accesibility-by-using-instead-of/

I’ve tried in vain to test a solution using Custom CSS, because when opening a saved copy it displays the footnote numbers in black. Perhaps this might help:

.footnote_plugin_index,
.footnote_plugin_index_combi {
	color: #000000;
}

Or this:

.footnotes_table .footnote_plugin_index,
.footnotes_table .footnote_plugin_index_combi {
	color: inherit !important;
}

I’m sorry for missing out on this. When I was debugging Footnotes accessibility changes in themes and just completed the abovementioned steps, other weird bugs needed fixes, and above all we needed to release because doing otherwise is inacceptable and was only devised to mitigate the impact of the March 1st accidental release.

I’ll try to complete debugging and release a v2.6.3 ASAP.

@spaceling,

Sorry please for pointing the wrong solution for the link color to be restored. The keyword is not inherit but unset as an equivalent of unchecking the rule.

But I still don’t get the link color back. As you’re using the link element, the footnote numbers in the list should be in #365DA0 color like the hyperlinks, but they aren’t, they’re black after disabling the table header color rule.

Another side effect of the need to replace these <‌td> elements with <‌th> is the change in font weight. Now the numbers are bold. Is that acceptable or even desired, or should it be reverted too?

Thank you for your response on the font weight and for sharing your thoughts about using table header cells from now on. The thorough investigation reported in https://a11y-101.com/development/tables points out that screen readers are unable to make sense of tables on their own, and only spell out tables correctly on the condition that the tables use HTML markup as intended.

So if there is no table caption, screenreaders present the table as a nameless thing; therefore to meet accessibility requirements by fulfilling expectations underlying to assistive technologies, without breaking the Footnotes reference container appearance in the process, I needed to conceal a table caption somehow but without using display: none or visibility: hidden because these are taken into account by screen readers.

Now the footnotes reference container is a particular table in that it uses table markup for layout. Initially it did follow best practice by using stacked divs with CSS, but the outcome was so bad it reverted to table layout. Turns out this is better for accessibility too, since as warned in https://a11y-101.com/development/tables, we can’t achieve the same with ARIA labels. But if footnote numbers are not in table header cells with scope=”row”, screen reader output is suboptimal. Thanks to @derivationfr issue report, that is now fixed, but now the job is to fix the appearance for sighted users. Thanks to your bug report we’re now closer to this goal—suspecting that other themes may need other fixes as well—or, ideally, everything is fixed now.

The problem is now how to get the table to display in three parts on desktop because this layout may be preferred, as you expressed in another thread, and it’s found on Wikipedia too (as two columns). I remember your preference and repeatedly thought at your response in the matter but considered that the plugin was still not working well and had more settings than it was able to deliver — the bugs in excerpts are fixed only since the current new bugfix released just one hour ago.