-
Notifications
You must be signed in to change notification settings - Fork 27
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
Are attributes supported for simplification? #143
Labels
i18n-needs-resolution
Issue the Internationalization Group has raised and looks for a response on.
Comments
We agree and plan to address easy language alternatives in module two - for which we should have a working draft the end of 2020. |
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
|
Closing issue since we have not been advised of any objections. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
i18n-needs-resolution
Issue the Internationalization Group has raised and looks for a response on.
(From your I18N self-review #133) (edited here for clarity)
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:
The text was updated successfully, but these errors were encountered: