- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Fri, 8 Mar 2013 07:09:45 +0000
- To: James Craig <jcraig@apple.com>
- Cc: "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>, Dominic Mazzoni <dmazzoni@google.com>
On 4 March 2013 19:21, James Craig <jcraig@apple.com> wrote:
> Not necessarily heavy customization. For example, this could be used to indicate a visible "required" state on required form elements:
>
> [required]::after, [aria-required="true"]::after {
> content: attr(data-loc-required), "required"; /* Visibly display "required" or localized equivalent. */
> aria-hidden: true; /* The required attr(s) already convey this info to the accessibility APIs, so don't convey it twice. */
> }
>
> Web Components seem like overkill for this case.
Is the scenario here one in which future browsers style @required by
default *and* support application of ARIA from stylesheets, and a
future developer wants to hide the default style and supply their own
without compromising the accessibility of @required?
A way to create CSS generated content that is not inserted into the
accessibility hierarchy would be useful, because it’s currently
difficult to generate decorative text with CSS:
decorative-content: attr(data-loc-required), "required"
Are there use cases for applying the other ARIA states and properties?
--
Benjamin Hawkes-Lewis
Received on Friday, 8 March 2013 07:10:32 UTC