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

Add discussion when best to meet objective - by author or best by user agent #325

Open
philljenkins opened this issue Oct 5, 2022 · 3 comments

Comments

@philljenkins
Copy link

The Abstract explains that:

"This document is for people who make web content (web pages) and web applications. It gives advice on how to make content usable . . . "

but does not explain and rarely even mentions the role of user agents (browsers + assistive technology). If it is expected that authors (designers and developers of content and application) best meet all these "8 User Story objectives" and all the "8 Design Objectives" without relying on browser extenions or ATs (user agents), then that needs to be made explicit.

If however, and this is recommended, some spectrum or trade-off beetween authors and user agents (UA) is a good, better, or best approach in meeting (or partially meeting) the specific objective, then that needs to be made explicit. I would recommend leaning towards the latter and being explicit when trying to meet the specific objective and include considerations for the UA to be included. Perhaps it will be determined that authors have more responsibility of certains types of content and applications and UA's have more responsibilities on other types of content and applications. Examples would be helpful.

I need to understand the language used, including vocabulary, syntax, tense, and other aspects of language.

For example, the author would be responsibe for determing the initial choices of terms and levels of vocabulalry, but the UA would provide the hooks and mechanism to get to definitions or to adaptations of the terms (whole chucks of content) and alternative levels of the vocabulary (or whole chucks of content). Such as a simplified version of "Terms and conditions" aternative vs the legally binding versions of "terms and conditions".

@shawna-slh
Copy link
Contributor

related resource: Essential Components of Web Accessibility

@alastc
Copy link
Contributor

alastc commented Oct 28, 2024

Hi @philljenkins,

I'm happy to be corrected by folks from the COGA TF, but I think part of the reason user-agents aren't mentioned is that the story for user-agent support is not a good one. Both in terms of what is available, and how easily people can use what is available. There is so little in the way of user-agent support that authors could expect to be used by real people, it isn't worth getting into.

Also, the content-usable document is aimed at authors, people creating websites etc. If user-agent support improves for some aspect, I assume the idea is to update the authoring advice.

However, it is something we're trying to tackle in WCAG 3. For example, building requirements that could be fulfilled by author or user-agent, and a mechanism to move from one to the other when support improves. Some of that you'll be able to see in the next publication, part of that you can see in the accessibility supported proposal.

@philljenkins
Copy link
Author

... story for user-agent support is not a good one.

We have some good examples, such as browser zoom to enlarge fonts & pages. We have lots of examples in assistive technology (AT) and that is exactly my point about good better best. It's best when the user decides using the browser+AT, not when the author/design decides what is the best "zoom level" for example.

... building requirements that could be fulfilled by author or user-agent, and a mechanism to move from one to the other when support improves.

hmm, that might work, but seems to be repeating the past failure of not recognizing the need to best meet the requirement in the browser (not by the author) and not advocating for improvements in the browsers. With chromium being open-source, seems we should have more leverage to improve the support needed.

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

No branches or pull requests

4 participants