Follow-up from "Fix TOC #null anchors, incidentally enabling TOC for other markup"

The following discussion from !241282 (merged) should be addressed:

  • @tkuah started a discussion: (+4 comments)

    @skkzsh

    We previously had Filter::HeadingAccessibilityFilter in this list. Now it's gone

Verifying a11y in each markup's integration rendering tests would require the same mock, which I think duplicates what that unit tests already cover. I'm not sure the testing strategy calls for that. If you think adding a11y assertions to each markup's integration rendering tests (Markdown, AsciiDoc, Org-mode, RST, MediaWiki, etc.) is worth pursuing, the scope and approach are probably best left to a separate discussion. For what it's worth, this filter isn't required for the fix. I added it for consistency with the other pipelines.

. It is kind of a test gap that no tests fail when we forgot to add HeadingAccessibilityFilter to the pipeline. Also - can we update the name to be more descriptive - it sounds more like a HeadingLocalizationFilter

Scope (added during planning)

Two deliverables, handled together in one stacked MR on top of !241282 (merged) (not yet merged):

  1. Close the test gap — add behavioural coverage so a markup pipeline missing the heading-anchor filter is caught (a filter was silently dropped with no failing test).
  2. Rename the filter — HeadingAccessibilityFilter → HeadingLocalizationFilter. The filter localizes the existing aria-labels on heading anchors, so the name should convey localization rather than generic accessibility.

The broader question of full a11y assertions in each markup's integration rendering tests is explicitly out of scope (deferred to a separate discussion per the MR thread). Full Why/How/What breakdown is in the Work Plan widget.

Edited by Asherah Connor