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

Consider conformance guidance for dialogs which contain large blocks of text #7708

Closed
scottaohara opened this issue Mar 15, 2022 · 6 comments
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. accessibility Affects accessibility document conformance topic: dialog The <dialog> element.

Comments

@scottaohara
Copy link
Collaborator

Per the dialog initial focus proposal, this unresolved comment has been moved here for further discussion:

In particular, authors must not include large blocks of text directly in dialog elements, as this is likely to cause the dialog element itself to overflow. Instead, a scrollable container element should be used, inside the dialog, to contain this text.

@domenic:

It seems difficult to come up with an automated conformance-checker check for this. But I think it's still worth expressing, even if it's not something that can be automated.

cc @sideshowbarker for thoughts on conformance checker rules concerning this topic.

@Yay295
Copy link
Contributor

Yay295 commented Mar 15, 2022

Why not make the dialog element scrollable by default, with max width and height to the screen width and height? I see there's a note in that proposal to not do that, so maybe it's already been discussed, but a reason isn't stated in the proposal.

@annevk annevk added document conformance accessibility Affects accessibility a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. topic: dialog The <dialog> element. labels Mar 16, 2022
@michael-n-cooper michael-n-cooper added a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. and removed a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. labels Mar 23, 2022
@domenic
Copy link
Member

domenic commented Aug 9, 2022

Regarding the question of which issues in #4184 (comment) should be considered blocking for writing up a spec of https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#initial-dialog-focus-logic : I think we should come up with an opinion here, but it is a minor question and should not block writing up a spec PR, as it's just a question as to whether to include or not include a single sentence in that PR.

I am interested in the opinion of folks like @sideshowbarker and @zcorpan on whether the proposed conformance requirement in the OP would be useful.

@zcorpan
Copy link
Member

zcorpan commented Aug 11, 2022

I object to this proposal.

I think it is inappropriate for HTML to require things about the styling in general. Document conformance requirements in HTML do not and should not have a CSS dependency. On the theoretical purity level, CSS is optional, and therefore the conformance of an HTML document should not change depending on whether CSS is applied. On a more practical level, the styling can change over time or depend on various things such as the viewport size, preferences for light mode vs dark mode, preferences for reducing motion, support for certain CSS features, and so on.

Recommendations for how to make dialogs accessible, including styling, seems appropriate for WCAG or so.

I would be OK with non-normative styling suggestions in a note in HTML, though.

@sideshowbarker
Copy link
Contributor

Since cases of document-conformance requirements that we can’t do automated checking for don’t need any support in conformance-checking tools, then from my point of view as HTML-checker maintainer, they’re just a no-op that I pay no attention to.

But in general from the point of view of trying to provide the right guidance for developers, I’m not very fond of adding requirements to the HTML spec that we can’t do automated checking for — because that leaves developers without any means to discover that they’re doing something that the spec formally states is non-conformant (except for those few developers who’ve happened to have read the spec).

So I think if we were to put wording about this for developers into the spec, it shouldn’t be normative — not even “should” — but would be better worded as a suggestion.

Recommendations for how to make dialogs accessible, including styling, seems appropriate for WCAG or so.

I was about to say the same thing. It seems like the WAI guides and tutorials are the place where developers already know and expect to find this kind of guidance — rather than in the HTML spec.

@scottaohara
Copy link
Collaborator Author

if anything is done in HTML, then it seems the following would be the way to go

I would be OK with non-normative styling suggestions in a note in HTML, though.

@josepharhar
Copy link
Contributor

if anything is done in HTML, then it seems the following would be the way to go

I would be OK with non-normative styling suggestions in a note in HTML, though.

I'm adding a non-normative note with this text in the pr:
#8199

Another important aspect of user behavior is whether dialogs are scrollable or not. In some cases, overflow (and thus scrollability) cannot be avoided, e.g., when it is caused by the user's high text zoom settings. But in general, scrollable dialogs are not expected by users, and authors should attempt to avoid them. In particular, authors must not include large blocks of text directly in dialog elements, as this is likely to cause the dialog element itself to overflow. Instead, a scrollable container element should be used, inside the dialog, to contain this text.

I suppose that I might have to change it to not use "must" in order for it to be non-normative, but we can figure that out in the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. accessibility Affects accessibility document conformance topic: dialog The <dialog> element.
Development

No branches or pull requests

8 participants