search

w3c / adapt

Semantics to describe user personalization preferences.
https://w3c.github.io/adapt/
Other
51 stars 27 forks source link

Alternative design for consideration: different layering #76

Closed samuelgoto closed 3 years ago

samuelgoto commented 6 years ago

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.

LJWatson commented 6 years ago

@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 commented 6 years ago

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).

lseeman commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

johnfoliot commented 3 years ago

@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.