WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: using aria too much

for

From: Birkir R. Gunnarsson
Date: Apr 13, 2019 8:50AM

ARIA is too permissive. We need more guidance on how to use it and
stronger semantic rules and requirements so tools can catch misuse
(including over use) of ARIA.
I'm drafting a set of blogs with suggestions on making ARIA use more
restrictive, starting with virtually eliminating global ARIA
attributes, but it's one of those ideas that I really want to do in
theory, but in practice I never find the time to complete the job.
I gots to kick myself in the behind and "get 'er done", to quote a
certain Cable Guy.


On 4/13/19, Mallory < <EMAIL REMOVED> > wrote:
> Just because I activate a button doesn't mean I want my focus shoved to the
> resulting content. Remember this would happen to sighted keyboarders too,
> and I'm thinking of tab panels where aria-controls was recommended for tabs
> to their panels-- nope nope nope. Tab panels aren't always designed visually
> to look like tab panels, so how can I know when my focus will be ripped out
> from under me and when it won't? (this is a separate problem anyway and one
> we'll likely never solve.)
>
> Another issue I run into with aria-controls is that it's supposed to not
> work on things not in the tree-- and I've seen more and more implementations
> in the wild where the controlled-thing you click to show is actually added
> to the DOM at that point-- and isn't there beforehand, or is display: none.
> It would work find in the event of a control *changing* some other content,
> and then allowing you to (at your leisure) move to that content.
>
> I'll tell you where I see way too much aria. People are aria-labelling
> everything. Every damn thing. Sometimes they aria-label long paragraphs with
> a word or two, but luckily the lack of interactive roles prevents the
> aria-label from overriding, but it's also being done on links and buttons.
> It's either too much or too little:
> button aria-label="click here to activate the menu toggle" (visible name:
> menu)
> a href aria-label="Description" (visible name: a buttload of text including
> a professor name, their department, room number, contact info...) yes, too
> much text for a link name but the aria-label is worse.
>
> cheers,
> _mallory
>
> On Fri, Apr 12, 2019, at 2:24 AM, David Engebretson Jr. wrote:
>> Have you all seen aria used too much?
>>
>> I'd like to find a balance where aria is useful and where it is a
>> hinderance
>> to usability.
>>
>> Has anyone experienced too much aria while navigating a web page? I sure
>> have... I'd enjoy hearing your stories.
>>
>> Aria-controls with JAWS has proven to be a booger as far as usability.
>> Sure
>> the ability to jump to the control with JAWSKey+alt+'m' puts virtual
>> cursor
>> focus on the element, but if the designer were to follow design patterns
>> they would expect the user focus is automagically brought to the element
>> in
>> question. If focus is brought to the element already, why would we need
>> the automagic reminder, "press JAWSKey+alt+'m' to move to the item"
>> (paraphrasing)?
>>
>> Why can't focus be brought to the aria-controls without any need for
>> reminder from the assistive technology we use? NVDA and Voiceover don't
>> need
>> keyboard interaction like JAWSKey+alt+'m' to offer a superior user
>> experience...
>>
>> I might be missing something basic. I've disabled auto forms mode in JAWS
>> to
>> overcome most of the issues I find with aria-controls with JAWS. Have you
>> found a better way to overcome usability issues with aria-controls and
>> JAWS?
>>
>> Thanks for your thoughts,
>> David
>>
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.