Are attributes supported for simplification?
aphillips opened this issue · 4 comments
aphillips commented
(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 commented
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 commented
Hi Addison,
For example, can the author separately address the alt attribute and the
content in this example:
<p alt="one value">Another value.</p>
Your example is non-valid code, and would be out of scope. (@alt can only
be applied on <img>)
Rephrasing your question however, ARIA could introduce a similar concern:
<p aria-label="one value">Another value.</p> (*)
(*) Why anyone would do this is beyond logic, but it is technically
possible to do this. A better example would be using <button>:
<button aria-label="click to submit your question">I'm feeling lucky</button>
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):
<a href="" aria-label="Read More about %ArticleHeadline%">Read More</a>
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
<#143 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJL442URWWIVQTTFBZ37ADRQLKX7ANCNFSM4MEHC7PQ>
.
--
*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 commented
Closing issue since we have not been advised of any objections.