Some considerations off the top of my head:

Semantics:

• TOC title is originally an h2, but because it is located before the h1 in the main content, we must apply aria-hidden=true to the title. Ideally it can be not hidden and located after the h1, but this will have to wait until all the navigation menus can be moved after the h1. That said, this isn't a high priority, and it could possibility be fixed in future navigation related work.

Scrolling:

• Auto opening/closing of sections via scroll should respect user motion preferences
• Auto opening/closing of sections should update expanded status of each list

Tab/keyboard behavior:

• Opening/closing of sections should be implemented with the checkbox hack to ensure keyboard support for no-js users

Opening/closing of sections should be implemented with the checkbox hack to ensure keyboard support for no-js users

@bwang I'm wondering whether or not the expand/collapse functionality should have no-js support at all. Highlighting the active section depends on JS, and the automatic expanding/collapsing while scrolling depends on that highlighting.

Do you think leaving the ToC in a fully expanded state for no-js users would be sufficient?

I personally think it would be fine to leave the ToC in a fully expanded state for no-js users. We might want to additionally hide the arrows for no-js users as they wouldn't work either way. It would also mean our markup could be a lot simpler, we'd just need to add an additional button to the markup for each expandable section.

@Jdrewniak @alexhollender_WMF I realized today that because the arrow button has a distinct behavior (pinning) from clicking the section heading, I believe this means we technically don't meet the WCAG minimum target size requirement. If clicking the arrow button had the same behavior as clicking the section heading, the small size wouldn't matter because the functionality is covered by the larger section heading.

In my very subjective opinion, this probably isn't a huge deal because the behavior for clicking on the arrow vs the section heading are both very similar, and pinning isn't an essential piece of functionality. Small target sizes are also more of a concern on mobile and touch devices, although it's still not great to have on desktop, i.e. using a mouse with hand tremors.

I bring this up just so y'all are aware, not suggesting we necessarily need to change anything. That said, it might be worth looking into how useful/discoverable it is to have 2 slightly different behaviors in the first place. Knowing that might help us feel more confident in making this tradeoff.

@bwang thanks for mentioning that. I am aware that the button is very small currently. We are still in the process of doing visual design for the table of contents so will keep that in mind.

When evaluating the accessibility requirements for the TOC we focused on DOM location, semantics, tab/keyboard behavior, and scroll behavior, especially as they relate to users that have JS disabled, are using screenreaders, or have motion disorders. Some of the considerations we identified early on were addressed when the scope was later reduced. I.e. the checkbox hack was no long necessary when the expand/collapse functionality was removed for no js users, and motion concerns were reduced after auto expand/collapse on scroll was removed after feedback from early testing. Other concerns around the TOC markup and location in the DOM were handled during feature development, or have been captured in other tasks (T303766).

Some smaller concerns still remain but can be reevaluated in the future.

• The target size of the arrow button is small, this will be considered in ongoing visual design for the TOC.
• The TOC doesn't use any animations or transitions, but it does auto scroll to keep active sections visible. We may want to consider testing how this impacts users with motion/attention issues in the future, and potentially disable auto scroll for certain users via the prefers-reduced-motion media query