Skip to content

Conversation

@emteknetnz
Copy link
Member

Issue #3135

Copy link
Member

@GuySartorelli GuySartorelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works locally, but:

  1. Please use an appropriate HTML landmark element as the parent of the island (most likely nav)
  2. If we're following wcag patterns, when we tab to the tree and a page is open, we should be at that page in the tree (see https://www.w3.org/WAI/ARIA/apg/patterns/treeview/examples/treeview-navigation/)

@emteknetnz
Copy link
Member Author

emteknetnz commented Dec 2, 2025

If we're following wcag patterns, when we tab to the tree and a page is open, we should be at that page in the tree

The underlying library (jstree) we're using is veeery old, brittle, and makes development hard. This recommendation would involve adding state management to the site tree

If we wish to do this, at this point I'm thinking we're best off pausing accessibility on the site tree specifically and just rebuilding the site tree in react, which needs to happen at some point.

Thoughts on that?

@GuySartorelli
Copy link
Member

The state should already be managed with a aria-current="page" attribute, assuming the state you mean is knowing which item to focus on when tabbing to the tree.

@emteknetnz
Copy link
Member Author

aria-current is being used on the tree right now

There's still a lot of work to do to get the site tree accessible

Given the work remaining, I think we should just rebuild the site tree in react at this point

@GuySartorelli
Copy link
Member

GuySartorelli commented Dec 3, 2025

I think that may be more difficult than you expect - the markup is at least partially done through explicit PHP methods which expect to return markup that updates the tree. Anyone customising those methods should expect their customisations to affect the tree markup.

Maybe lets discuss offline and report back here with a decision.

@emteknetnz
Copy link
Member Author

Chatted offline, agreed that while it's not ideal, it's acceptable from a backwards compatibility perspective if rebuild in react and make that default, and we retain the old API and functionality which can be used instead of the new react version via config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants