E-mail List Archives
Thread: using aria too much
Number of posts in this thread: 4 (In chronological order)
From: David Engebretson Jr.
Date: Thu, Apr 11 2019 6:24PM
Subject: using aria too much
No previous message | Next message →
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
From: Mallory
Date: Sat, Apr 13 2019 3:02AM
Subject: Re: using aria too much
← Previous message | Next message →
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
>
> > > > >
From: Birkir R. Gunnarsson
Date: Sat, Apr 13 2019 8:50AM
Subject: Re: using aria too much
← Previous message | Next message →
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 ADDRESS 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.
From: Mallory
Date: Mon, Apr 15 2019 3:40AM
Subject: Re: using aria too much
← Previous message | No next message
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 ADDRESS 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.
> > > > >