Open myasonik opened 1 month ago
The current layout was created with the help from the author of Material for MkDoc's. They currently rely heavily on the current approach. I would like to loop in them for any discussions on the possibility of restructuring the tab container.
@squidfunk, any thoughts on this?
I understand the concerns, and improving accessibility is always a priority for us. However note that this implementation is one of the very few tab implementations that does not rely on JavaScript – it works without JavaScript. This is also one of the goals in Material for MkDocs. We gravitated towards this solution in https://github.com/facelessuser/pymdown-extensions/issues/1415.
If we can improve accessibility, we're happy to accept PRs, but it's unlikely that we change the implementation completely. For instance, adding the role
attributes could be something done here, in this project, and it is not expected to have any impact on the rendering. If we can dynamically add aria-*
attributes when tabs are used and JavaScript is available, we're happy to do so. Again, PR appreciated.
I'm kind of on the same page here. I'm open to accessibility changes that could be made here, but I would like to avoid a complete restructure.
My main interest was to get insight on possible directions. Do aria attributes need to be dynamic? Is there anything about the way we currently do things that impedes accessibility goals, and if so, which ones?
The statements was made "The DOM needs to be considerably rewritten", but I'm not sure there was clear reasoning specifying exactly why this is. What specific functionality is impossible to implement in our current approach?
I agree that functional tabs with pure CSS is an asset. With that said, I would at least like to understand the any negatives if they can be articulated clearly.
Sorry about the quality of this video (and the audio especially!) but I had to compress it quite a bit to get it under GH's size limit. Hopefully this illustrates some of the issues.
Videos are great, and I'll check it as soon as I can, but can you summarize the main points why the current structure can not be adapted and requires an overhaul? Ideally, we could adapt the current layout to improve accessibility.
The current structure is something along the lines of:
<input type="radio">
<label><a>Tab name</a></label>
<div>Tab content</div>
To work with assistive tech, it needs to have a structure similar to what I mention at the top of the ticket.
The current structure:
label > a
) which causes issues for screen readers and keyboard focusIf more resources on accessible implementations would be helpful, let me know! Happy to provide links to more robust implementation guides.
If an accessible implementation of tabs is not feasible, 3 things can be improved to mitigate some problems:
<input>
(to highlight the associated <label>
) – this will probably still require moving the <input>
elements to directly precede their associated <label>
rather than all being at the start<a>
Use better hidden styles for the <input>
position: absolute; transform: scale(0);
is one simple option but this implementation is more battle testedThis still doesn't expose any correct tab semantics and may still be confusing but it should at least reduce bugs across assistive tech.
Is this true for the alternate style that is available? Are you aware of the alternate style vs the default?
Granted, we not currently apply roles to worker yet, but I want to make sure we are not just looking at the default or the alternate approach style.
I enabled a screen reader and played with this a bit. I at least have a better feel for what doesn't work, and even when adding roles and such, I see that the screen reader does seem to expect things to be configured a certain way. You can kind of get aspects of it to work without following things exactly, but it seems you can't get everything to work. I will play with this more.
Is this true for the alternate style that is available? Are you aware of the alternate style vs the default?
Hadn't seen it before but just checked it out and it seems to be largely the same.
I enabled a screen reader and played with this a bit... I will play with this more.
That's awesome - thanks for jumping into the deep end!
Description
The rendered tabs are missing a few things needed to create an accessible experience.
Spec example implementation can be found in the APG
The needed changes:
The DOM needs to be considerably rewritten
The basic structure should be:
Not needed per spec but best practice for unknown tab content:
tabindex="0"
to tabpanelsMinimal Reproduction
Version(s) & System Info