Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State machine transitions example #22

Open
scottaohara opened this issue May 7, 2022 · 3 comments
Open

State machine transitions example #22

scottaohara opened this issue May 7, 2022 · 3 comments
Labels
a11y accessibility issues

Comments

@scottaohara
Copy link

This example was confusing to me until I realized that some of these buttons likely should have been communicated as being disabled until whatever condition was necessary to enable them.

The changing content should be marked up as being within a live region. E.g., the <output> element would have been expected here, or at least an aria-live=polite on the <div> that the CSS content is modified within. It's unfortunate that CSS content is not text-selectable. I could see this being used in a situation where someone would potentially want to copy the output content, but that'd not be presently possible.

@jerivas
Copy link
Member

jerivas commented May 12, 2022

Agree, I don't think the intent was to update the text in the <div> per se, but we struggled to find a purely presentational example that could showcase the transitions and validation, hence the disclaimer on that section:

However, it's not yet clear that there are entirely presentational (CSS-only) use-cases.

@scottaohara
Copy link
Author

scottaohara commented May 12, 2022

i'm not sure i understand that particular qualifier here, since none of the examples were entirely presentational. all of them had some level of needing to communicate programmatic a11y information. so, i read that, but it made no sense as to what it was trying to indicate.

@mirisuzanne mirisuzanne added the a11y accessibility issues label May 23, 2022
@mirisuzanne
Copy link
Member

Yeah, that confusion makes sense to me. It's pretty clear here that even the use-cases most limited to some aspect of the presentation/style (eg color mode) still require communication of the purpose & current state of the toggle to users. In practice, even the most 'presentational' concerns become semantically meaningful as soon as we add interactivity - which is the entire purpose of this proposal in the first place. It will be impossible to move forward without addressing that reality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y accessibility issues
Projects
None yet
Development

No branches or pull requests

3 participants