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.

Sign up for GitHub

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

Jump to bottom

Alternative design for consideration: different layering #76

Closed
samuelgoto opened this issue May 21, 2018 · 6 comments
Closed

Alternative design for consideration: different layering #76

samuelgoto opened this issue May 21, 2018 · 6 comments
Assignees
@johnfoliot
Labels
1) content module structure Ways to structure the vocabulary that impact its features

Comments

@samuelgoto
Copy link

Forking from this thread where this originally came up.

So a user agent could make this changes before the page is rendered to accommodate his personal preferences

What makes us believe that this is the responsibility of the User Agent as opposed to the content author? That is, what makes us believe that the content author should declaratively state what are the semantics of the affordance and let the user agent figure out what to do?

Is there anything that this declarative affordance (i.e. the aui-action property) unlocks that couldn't be done before by the developer with custom CSS/HTML/JS (e.g. something that crosses security boundaries or has access to lower level APIs)?

What is it that we are buying moving this / baking this to the user agent layer? Consistency? Ergonomics? Implementation cost? Composition? Lower level access (e.g. ARIA gives declarative access to screen reader's API)?

What other alternatives have we explored to satisfy this use case? Why shouldn't we expose a programmatic/imperative javascript API like:

// returns true if the user has a preference for text over pictures
if (document.preferences.textToPictures) {
  // do stuff, hide stuff, show stuff
  // actual color of the bikeshed TBD
}

and let the developer figure out what to do with that setting (isomorphic question to "why should this be the responsibility of the user agent")?

Or maybe a media query for CSS that enables you to write a selector to change your UI based on the user preference? E.g.

// Shows numbers in text
@easylang .numbers-to-text {
  display: block;
}

// By default, hides them
.numbers-to-text {
  display: none;
}

// Shows large numbers by default.
@easylang .large-numbers {
  display: none;
}

With the following HTML structure:

<p>There are <span class="large-numers">13i828230840923840234</span><span class="numbers-to-text">a lot of</span> of users</p>

Importantly, in this alternative design, the responsibility of what to do with the UI/UX is onto the developers rather than the User Agent, and the User Agent is only responsible for managing preferences and for brokering that in a safe way with the developer.

Sorry if this is a silly question, but I couldn't find an immediate answer reading your docs.
This was referenced May 21, 2018
Closed
Open
@LJWatson
Copy link

@samuelgoto wrote:
<What makes us believe that this is the responsibility of the User Agent as opposed to the content author? That is, what makes us believe that the content
author should declaratively state what are the semantics of the affordance and let the user agent figure out what to do?<

Convenience and consistency seem to be likely reasons.

It's easy for an author to use an HTML element because the UA handles the rendering, interaction, and accessibility for them. If we make it just as convenient for authors to use the PS attributes, it's likely to aid adoption and subsequent use.

It is possible for authors to change the default rendering and interaction for HTML elements, but to some extent that leads to the inconsistency of presentation we're trying to overcome with the PS attributes.

@samuelgoto
Copy link
Author

samuelgoto commented May 23, 2018 •
edited
Loading

Convenience and consistency seem to be likely reasons.
It's easy for an author to use an HTML element because the UA handles the rendering, interaction,
and accessibility for them. If we make it just as convenient for authors to use the PS attributes, it's
likely to aid adoption and subsequent use.

I'm not sure I buy this line of thinking. A low-level API doesn't preclude ergonomics. Specifically, it moves that opinion to userland, but doesn't preclude an opinion about ergonomics to be formed. Here is an example:

<html>
  <head>
    <script src="http://jquery.com/personalization-semantics.js">
  </head>
  <body>
    <span aui-action="redo">Redo</span>
  </body>
</html>

So, web developers are still expected to be using a declarative/ergonomic notation, but what enables that is userland code (e.g. a jquery polyfill) rather than the user agent.

If anything, I expect ergonomics to be better if taken at userland, because userland code can iterate a lot faster than user-agent standards, meaning that you'd get a lot more innovation/competition there which typically fosters better results (there are more people thinking about that problem).

@michael-n-cooper michael-n-cooper added the structure Ways to structure the vocabulary that impact its features label Jun 18, 2018
@lseeman
Copy link
Contributor

lseeman commented Jul 25, 2018

some of the suggestions is exactly what the implemetions so far have done. some of your examples are exactly what the user implementations are doing   such as using  css at  https://a11y-resources.com/developer/adaptable-ui-personalisation or an json triggered extension at http://accessibility.athena-ict.com/personlization.shtml
Relevant wiki pages are https://github.com/w3c/personalization-semantics/wiki/Implementations-of-Semantics and https://github.com/w3c/personalization-semantics/wiki/Architectural-issues (we should populate it)

@lseeman
Copy link
Contributor

lseeman commented Jul 25, 2018

the author seas what the intent of the content is 9which he knows) the user agent, based on possible user setting , can the provide the appropriate support to the individual user. for example, making it a familuer icon that the user knows (and does not have to learn)

@ghost
Copy link

ghost commented Aug 28, 2018

Calling additional resources can be expensive. Also as a matter of influencing disability/accessibility policy, an optional library or plugin vs. native support further perpetuates the idea of accessibility as something extra or optional. Particularly within the cognitive disability which receives the least amount of focus in the landscape of accessibility.

@lseeman lseeman assigned lseeman and unassigned lseeman Mar 16, 2020
@johnfoliot
Copy link
Contributor

@samuelgoto asked:

What makes us believe that this is the responsibility of the User Agent as opposed to the content author?

Part of the answer is in the definition of "user-agent" - which is MORE than just the web browser. In fact, here it is actually the 'stack' of technologies that work together to produce the end user result.

This means that it could: a) have native browser support, b) be handled by third-party software at the OS level (similar to other Assistive Technologies such as screen readers and screen magnification tools), c) it could be handled via a 3rd-party browser extension, or 4) there are some instances where 'content conversion' might happen at a proxy server level (where the user is authenticated, and their user-profile is then stored and applied as needed) - the point being that there are multiple insertion points for 'technology' (the user-agent stack).

From the authoring level, the primary point of the emergent spec is to streamline and facilitate the attachment of metadata at the element level, using a controlled set of reserved terms and definitions (taxonomies) in a fashion similar to HTML5's @autocomplete - an attribute that has both native browser support, but ALSO support in 3rd-party user-agents (password tools like LastPass for example).

Closing thread as overcome by time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@johnfoliot johnfoliot

Labels
1) content module structure Ways to structure the vocabulary that impact its features
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@samuelgoto @johnfoliot @michael-n-cooper @LJWatson @lseeman @snidersd