[Docs] Our tabbed pages in our side nav are problematic for keyboard/focus/screen reader accessibility

[cee-chen]

CC @1Copenut

Example tabbed page: https://elastic.github.io/eui/#/guidelines/writing/guidelines

Problem 1: Screen reader page announcements

Our normal screen reader live region does not register switching clicking "Guidelines" and "Examples" in the sidebar as a page change because the parent section is not changing, so no announcements are made or indication that the page content has changed.

Problem 2: Focus accessibility

Because our screen reader live region is not registering a change, focus is not resetting from the side nav back to the top of the page. It's also kind of questionable as to whether focus should be reset back up to the top of the page: in theory, since this is a sub section of the page, focus be automatically set to the tab (making it easy for consumers to hop to the tabs contents).

What complicates the above approach however is the fact that we default to the first tab being highlighted/shown even when the parent level section is clicked (e.g., click the top level "Writing" link and notice that "Guidelines" is automatically visible and bolded). On initial page load we would likely not want to auto focus the tab, only when already on the page.

[1Copenut]

I've been looking at the ARIA authoring pattern for tabs today. The navigation pattern on our EUI pages with peer content sections like Guidelines | Examples don't feel like true tabs for several reasons:

1. Our a[role="tab"] links are not in a roving tab index. Each one is focusable instead of the group taking focus and users traverse with the arrow keys.
2. The tab links have fully qualified URLs that resolve to unique pages. These can be copy/pasted into the URL bar and will also resolve. True tab widgets are coded as buttons and swap an in-page container.
3. The selected tab doesn't have a corresponding tabpanel. There's not a clear relationship between the selected tab and its content.

One thought I had about the navigation would be to treat "tab" links like we do top-level pages. That is, setting focus back to the top of the page and announcing the page as "Writing Guidelines" or "Writing Examples". This makes the most sense to me because we're auto-selecting the first tab link anyway. There's no "Writing" page a level higher than "Guidelines".

This does require more logic to check for second-level links and add that string to the page title, but gets us away from the problems @constancecchen outlined in the original ticket.

[github-actions[bot]]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.