WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Where does it say to use native HTML features rather than re-create them in ARIA and JS?

for

Number of posts in this thread: 5 (In chronological order)

From: Tyllick,Cliff S (HHSC/DADS)
Date: Thu, Dec 22 2016 10:40AM
Subject: Where does it say to use native HTML features rather than re-create them in ARIA and JS?
No previous message | Next message →

Where in the WAI-ARIA Authoring Practices does it specify that WAI-ARIA is to be used only when native HTML won't suffice?

Or even that it's best practice?

I know it's there, but it just isn't immediately jumping out to me.

At least I think it's there. If not there, where is it?

Cliff

Cliff Tyllick
EIR Accessibility Coordinator
Texas Health & Human Services Commission
512-438-2494
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

*Please note* My email address has changed. Please be sure to update your contact information with my new email address.

From: Beranek, Nicholas
Date: Thu, Dec 22 2016 10:46AM
Subject: Re: Where does it say to use native HTML features rather than re-create them in ARIA and JS?
← Previous message | Next message →

Hey Cliff,

SC 4.1.2 Name, Role, Value calls out a few sufficient techniques to solve for it:

G10 relates to custom components:
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G10

G108 calls out standard form controls as 'documented and supported features-:
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G108

There are other sufficient techniques dependent upon your situation. I suggest you check them out!

https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

Nick

--
Nick Beranek
Digital Accessibility Team

On 12/22/16, 12:40 PM, "WebAIM-Forum on behalf of Tyllick,Cliff S (HHSC/DADS)" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:

Where in the WAI-ARIA Authoring Practices does it specify that WAI-ARIA is to be used only when native HTML won't suffice?

Or even that it's best practice?

I know it's there, but it just isn't immediately jumping out to me.

At least I think it's there. If not there, where is it?

Cliff

Cliff Tyllick
EIR Accessibility Coordinator
Texas Health & Human Services Commission
512-438-2494
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

*Please note* My email address has changed. Please be sure to update your contact information with my new email address.



The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: Steve Faulkner
Date: Thu, Dec 22 2016 10:47AM
Subject: Re: Where does it say to use native HTML features rather than re-create them in ARIA and JS?
← Previous message | Next message →

On 22 December 2016 at 17:40, Tyllick,Cliff S (HHSC/DADS) <
= EMAIL ADDRESS REMOVED = > wrote:

> Where in the WAI-ARIA Authoring Practices does it specify that WAI-ARIA is
> to be used only when native HTML won't suffice?


Unsure whether it is stated in the authoring practices doc, but there are 2
places this is stated:

In the ARIA 1.1 spec:

When a feature in the host language with identical role semantics and
> values is available, and the author has no compelling reason to avoid using
> the host language feature, authors should use the host language features
> rather than repurpose other elements with WAI-ARIA.

https://www.w3.org/TR/wai-aria-1.1/#host_general_conflict

In Notes on using ARIA in HTML:

2.1 First rule of ARIA use
> If you *can* use a native HTML element or attribute with the semantics
> and behaviour you require *already built in*, instead of re-purposing an
> element and adding an ARIA role, state or property to make it accessible*,
> then do so*.


http://w3c.github.io/aria-in-html/#rule1


--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Bryan Garaventa
Date: Thu, Dec 22 2016 11:02AM
Subject: Re: Where does it say to use native HTML features rather than re-create them in ARIA and JS?
← Previous message | Next message →

It's also very important not to use conflicting roles on native interactive elements, and preferably, don't use ARIA roles on any native interactive elements.

E.G I've seen recently where role="button" was added to input+type="text" elements, making them totally inaccessible using VoiceOver in iOS, and role="listbox" on native HTML select elements which caused other issues to occur, and others adding roles to select element option elements with the same inaccessible results.

These are all extremely bad practices.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com


From: Tyllick,Cliff S (HHSC/DADS)
Date: Thu, Dec 22 2016 11:21AM
Subject: Re: Where does it say to use native HTML features rather than re-create them in ARIA and JS?
← Previous message | No next message

Thanks, Steve!

Rule 1 is specifically what I was looking for.

Others suggested I rely on the WCAG Success Techniques. I don't go there for a couple of reasons:
- They are organized rather arcanely--the technology of the solution plus the somewhat arbitrary sequence number in which the technique was considered for review. That makes it hard to find the one that gives the best, most specific answer available--and to know when I have found it.
- They don't do a particularly good job of distinguishing between possible practices and best practices. For example, look up all the available Success Techniques for implementing headings.

As a result, they are too often better for starting long and sometimes informative discussions than for resolving definitively debates about best practices.

Steve, thanks again!

Cliff

Cliff Tyllick
EIR Accessibility Coordinator
Texas Health & Human Services Commission
512-438-2494
= EMAIL ADDRESS REMOVED =