Are attributes supported for simplification?

[aphillips]

(From your I18N self-review #133) (edited here for clarity)

We do define attribute names and values as tokens that are human readable but we don't expect those to be localized. However we do have content simplification that does have alternative text descriptions.

Note that some natural language in markup documents (such as HTML) appears in attributes. Do you have a scheme for "simplifying" that text as distinct from text contained by markup elements?

For example, can the author separately address the alt attribute and the content in this example:

<p alt="one value">Another value.</p>

[lseeman]

We agree and plan to address easy language alternatives in module two - for which we should have a working draft the end of 2020.

[johnfoliot]

Hi Addison,

For example, can the author separately address the alt attribute and the content in this example:

Another value.

Your example is non-valid code, and would be out of scope. (@alt can only be applied on )

Rephrasing your question however, ARIA could introduce a similar concern:

Another value.

(*) (*) Why anyone would do this is beyond logic, but it is technically possible to do this. A better example would be using : I'm feeling lucky Currently, ARIA has strong mojo - ARIA attribute values override native semantics and values in the accessibility tree of the DOM - always, per existing specifications. So for assistive technology like screen readers, what would be audible would be "click to submit your question" (as opposed to the on-screen "I'm feeling lucky"). In fact, this technique is often used to address multiple "Read More" buttons on a single news site page (for example): Read More I think the scenario you envision is: "what will our spec do regarding conflict resolution?" - to which we've not really addressed this explicitly (in part because we are not creating an app nor an API, but simply expanding the author-ability to apply element level semantics for further machine processing). As an accessibility consultant, I'd warn the content owner about your proffered example (or my revision of it) as being problematic from a usability perspective, but there the existing conflict resolution is that the ARIA value is what is exposed in the accessibility tree of the DOM (and announced/expressed by the AT). Whether we want helper apps in the future to follow that model, or to respect the on-screen text and 'ignore' the normal 'over-ride' functionality of ARIA would be, I think left to tool vendors (process the DOM, or the accessibility tree of the DOM?). In a perfect world (and allowing for non-sighted users who also have cognitive disabilities) the individual user could make the final determination, and tooling would offer that as a user-setting. In a more traditional scenario (alternative text for an image, written in German), then *IF* the tooling had a 'screen reader mode" (user setting), then yes, it would/could/should be applicable to text alternatives and/or other string text attribute values as required. Does that help? JF On Thu, May 7, 2020 at 10:55 AM Lisa Seeman wrote: > We agree and plan to address easy language alternatives in module two - > for which we should have a working draft the end of 2020. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > -- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com "I made this so long because I did not have time to make it shorter." - Pascal

[snidersd]

Closing issue since we have not been advised of any objections.

[aphillips]

I was actioned by I18N to reopen this issue, however I note that @lseeman's note of May 7 suggests that this is a feature for v2, which is an acceptable resolution.