WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: using aria too much

for

From: Mallory
Date: Apr 15, 2019 3:40AM

I'd spread those blogposts around everywhere if you do get a Round Tuit, Birkir.

On Sat, Apr 13, 2019, at 4:50 PM, Birkir R. Gunnarsson wrote:
> 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.
> > > > >