E-mail List Archives
Thread: forms and multiple aria-live regions
Number of posts in this thread: 18 (In chronological order)
From: Swift, Daniel P.
Date: Thu, May 24 2018 11:30AM
Subject: forms and multiple aria-live regions
No previous message | Next message →
We are in the process of updating our forms. A typical form will be broken into fieldsets and at the top of each fieldset we have an empty unordered list which would contain a summary of errors. When the form is submitted, javascript runs and validates the form. If required fields are empty (for instance), the unordered list closest to the required field gets populated with a message indicating to the user that information is missing.
I was hoping that we could use aria-live on each unordered list but that doesn't seem to be working especially if the page is also showing/hiding content where we are already using aria-live.
Are we doing something wrong or is there a better solution?
Thanks!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Henry, Michael (IntelliDyne)
Date: Thu, May 24 2018 12:59PM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
I'm no expert and have struggled with proper form validation error messages, too, but we do something slightly different (if I understand you correctly), and I wouldn't mind input from others on our solution.
We Have the error summary box at the top of the form, hidden on default. When the form is submitted with errors/improper input, the error summary box appears at the top of the form, with an unordered list describing each invalid input (eg, "Address is required"). Each of those <li>s is a link to the specific <input> it refers to.
The Error Summary box has a role=alert.... but as I write this, it's dawning on me that it should probably also include "aria-live=assertive" (or "polite"?), and "aria-relevant= additions" as well.
And for this to work, the Error Summary box needs to be in the markup (not using display:none) on page load, so the browser and assistive technologies are aware of it.
Sorry that I seem to have raised more questions than answers. Maybe someone can help both of us?
---
Mike S. Henry
Creative Services Lead
IntelliDyne Contract Employee
Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
Desk: (703) 882-3962
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Swift, Daniel P. < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, May 24, 2018 1:30:23 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] forms and multiple aria-live regions
We are in the process of updating our forms. A typical form will be broken into fieldsets and at the top of each fieldset we have an empty unordered list which would contain a summary of errors. When the form is submitted, javascript runs and validates the form. If required fields are empty (for instance), the unordered list closest to the required field gets populated with a message indicating to the user that information is missing.
I was hoping that we could use aria-live on each unordered list but that doesn't seem to be working especially if the page is also showing/hiding content where we are already using aria-live.
Are we doing something wrong or is there a better solution?
Thanks!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: glen walker
Date: Thu, May 24 2018 1:41PM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Michael, if you have role="alert" then you already (implicitly) have
aria-live="assertive". You don't need to add it. And if you don't specify
aria-relevant, the default is "additions text", so you're ok there too. I
like how you have your errors organized, with the list items being links to
the field that's in error. That's what I do too. But I try to limit my
use of role="alert" or aria-live="assertive" because if you have multiple
live areas being updated, it's possible an assertive message can clear the
other assertive messages (according to the spec). I rarely have anything,
including error messages, just just have to be read immediately. Usually
aria-live="polite" is sufficient.
Daniel, the problem you're seeing/hearing *might* be caused by multiple
assertive areas, but that's just a guess. It's possible one assertive
message is clearing the others. You could try a polite region to see if
that helps. Also, I'm not sure on the timing of hidden objects and
aria-live, in that if you update a live region while it's hidden, and then
unhide it in the next line of javascript, if that'll work. You could try
unhiding it first, then updating the live area (if you're not doing that
already).
Glen
On Thu, May 24, 2018 at 12:59 PM, Henry, Michael (IntelliDyne) <
= EMAIL ADDRESS REMOVED = > wrote:
> I'm no expert and have struggled with proper form validation error
> messages, too, but we do something slightly different (if I understand you
> correctly), and I wouldn't mind input from others on our solution.
>
>
> We Have the error summary box at the top of the form, hidden on default.
> When the form is submitted with errors/improper input, the error summary
> box appears at the top of the form, with an unordered list describing each
> invalid input (eg, "Address is required"). Each of those <li>s is a link to
> the specific <input> it refers to.
>
> The Error Summary box has a role=alert.... but as I write this, it's
> dawning on me that it should probably also include "aria-live=assertive"
> (or "polite"?), and "aria-relevant= additions" as well.
>
>
> And for this to work, the Error Summary box needs to be in the markup (not
> using display:none) on page load, so the browser and assistive technologies
> are aware of it.
>
>
> Sorry that I seem to have raised more questions than answers. Maybe
> someone can help both of us?
>
>
>
> ---
> Mike S. Henry
> Creative Services Lead
> IntelliDyne Contract Employee
> Supporting Enterprise Infrastructure (formerly Military Health System
> Cyberinfrastructure Services - MCiS)
> Desk: (703) 882-3962
>
> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of
> Swift, Daniel P. < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, May 24, 2018 1:30:23 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] forms and multiple aria-live regions
>
> We are in the process of updating our forms. A typical form will be
> broken into fieldsets and at the top of each fieldset we have an empty
> unordered list which would contain a summary of errors. When the form is
> submitted, javascript runs and validates the form. If required fields are
> empty (for instance), the unordered list closest to the required field gets
> populated with a message indicating to the user that information is missing.
>
> I was hoping that we could use aria-live on each unordered list but that
> doesn't seem to be working especially if the page is also showing/hiding
> content where we are already using aria-live.
>
> Are we doing something wrong or is there a better solution?
>
> Thanks!
>
> Dan Swift
> Senior Web Specialist
> Enterprise Services
> West Chester University
> 610.738.0589
>
> > > > > > > > >
From: Henry, Michael (IntelliDyne)
Date: Thu, May 24 2018 1:44PM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Cool. Thanks.
---
Mike S. Henry
Creative Services Lead
IntelliDyne Contract Employee
Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
Desk: (703) 882-3962
From: Jonathan Avila
Date: Thu, May 24 2018 6:13PM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
In my experience use of role alert may cause screen readers to announce content outside the current tab. This can be problematic when the user is on another tab and ARIA alerts are fired that are not emergencies.
Jonathan
From: Birkir R. Gunnarsson
Date: Thu, May 24 2018 7:12PM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
I think this set up is less than ideal. The errors may be located
farther away from the invalid input fields making it difficult for
people using screen magnification to discover them.
It is better design to place the error message inline with the invalid
field and connect the two using aria-describedby (make sure only to do
this when the error message is visible).
That being said, you may be too far along in the process to change it now.
If you stick with your setup the key is to place focus on the first
error message when it is displayed rather than using live regions.
Ideally the error message should be a link to the associated input
element, making it faster for users to get to it.
I created a side-by-side comparison the techniques using HTML5 validation.
I need to upload it to Codepen, I'll try to fit that into my schedule
tomorrow and post back to this thread with links.
On 5/24/18, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> In my experience use of role alert may cause screen readers to announce
> content outside the current tab. This can be problematic when the user is
> on another tab and ARIA alerts are fired that are not emergencies.
>
> Jonathan
>
>
From: Mark Magennis
Date: Fri, May 25 2018 3:36AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Hi Daniel,
I think there is a better solution. You don't need to use aria live regions for error warnings that appear after submitting the form. Only for errors that appear dynamically, after moving away from a field.
For submission error warnings, a general warning, e.g. "There are errors on this form. Please fix them and resubmit the form." (or something nicer), can be placed on the page above the form (not within it). On page load, focus can be moved to this warning message, so it is read immediately by screen readers and is (probably) within the viewport for users using screen magnification.
For each field that has an error, the specific warning message can be placed adjacent to the field and included within the field's label using aria-labelledby (or aria-describedby), to ensure it is announced by screen readers. It should also be hidden to AT using aria-hidden="true" so it is not read again by a screen reader in browse mode (while arrowing through the page). All fields that do not have errors can be given tabindex="-1" and they and their labels can be hidden to AT using aria-hidden="true". This is to make it quick for keyboard and screen reader users to correct the errors and resubmit the form without having to tab through all the fields (some users don't know they can hit ENTER to submit the form and it doesn't work on some field types anyway).
Regards,
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: Swift, Daniel P.
Date: Fri, May 25 2018 6:11AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Thanks to everyone for the feedback. One thing that I neglected to mention is that we are also validating the individual field when the field losses focus. In retrospect, this is probably the point in which we need to use aria-live ... not at the end (client-side). I am going to take this approach instead.
Birkir -- you raise an excellent point regarding screen magnification which I hadn't considered. I look forward to your Codepen.
Thanks again, everyone!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Henry, Michael (IntelliDyne)
Date: Fri, May 25 2018 6:28AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
If you don't mind a followup/clarification question:
As I mentioned, we're using the Error Summary box at the top of the form, but (although it's in the html source on page load) it uses style=display:none to keep it visually hidden until needed, at which point that style is removed.
Does that still work with AT?
I read the following on the mozilla developer site (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions#Preferring_Specialized_Live_Region_Roles) and it seems like having the empty error box hidden on load might cause it not to be read when changed to display:block.
Assistive technologies will announce dynamic changes in the content of a live region. The live region must first be present (and usually empty), so that the browser and assistive technologies are aware of it. Any subsequent changes are then announced.
---
Mike S. Henry
Creative Services Lead
IntelliDyne Contract Employee
Supporting Enterprise Infrastructure (formerly Military Health System Cyberinfrastructure Services - MCiS)
Desk: (703) 882-3962
From: Mark Magennis
Date: Fri, May 25 2018 6:51AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Dan,
When using the live region for error messages when a field loses focus, make sure the warning text explicitly refers to the field it relates to. Otherwise, the user may think it applies to the field they have just tabbed into, since it will be read in conjunction with the screen reader announcing that field. E.g.
"name"
>TAB
"email", "you must fill in this field"
Where the error was actually referring to the name field.
So the warning should be "you must fill in the name field".
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: Tim Harshbarger
Date: Fri, May 25 2018 7:34AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Yes, that should still work with AT like screen readers.
I suspect that when the article uses the word "present", it just means that the elements are part of the DOM rather than the elements are visible.
Thanks!
Tim
suspect
From: Henry, Michael (IntelliDyne)
Date: Fri, May 25 2018 7:43AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Thank you very much! I love this forum.
-Mike
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Tim Harshbarger < = EMAIL ADDRESS REMOVED = >
Sent: Friday, May 25, 2018 9:34 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] forms and multiple aria-live regions
Yes, that should still work with AT like screen readers.
I suspect that when the article uses the word "present", it just means that the elements are part of the DOM rather than the elements are visible.
Thanks!
Tim
suspect
From: Swift, Daniel P.
Date: Fri, May 25 2018 7:55AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Another excellent point - thanks, Mark!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Birkir R. Gunnarsson
Date: Fri, May 25 2018 9:17AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Make sure to place aria-live on the parent of the element that gets
displayed, not on the eleent itself.
bad:
<div aria-live="polite" style="display: none;">There were errors</div>
Good
<div aria-live="polite">
<div style="display: none;">there were errors</div>
</div>
Screenreaders are instructed to announce live region content when it
is added or changed.
In the bad case the content isn't changed,only the visibility of the element.
Some screen readers may announce it regardless, but I think your
results will not be reliable.
In the second case, updating the visibility of the child element
effectively adds content to the live region, so it should reliably be
announced.
I'll get to the code pends over the weekend, today is unexpectedly busy.
On 5/25/18, Swift, Daniel P. < = EMAIL ADDRESS REMOVED = > wrote:
> Another excellent point - thanks, Mark!
>
> Dan Swift
> Senior Web Specialist
> Enterprise Services
> West Chester University
> 610.738.0589
>
>
From: glen walker
Date: Fri, May 25 2018 11:06AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
Birkir, just to clarify, your example is good when you're hiding/unhiding
child elements but if the change is just to the text inside the element,
then having aria-live on the child is fine.
Glen
On Fri, May 25, 2018 at 9:17 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> Make sure to place aria-live on the parent of the element that gets
> displayed, not on the eleent itself.
> bad:
> <div aria-live="polite" style="display: none;">There were errors</div>
> Good
> <div aria-live="polite">
> <div style="display: none;">there were errors</div>
> </div>
>
From: Jonathan Avila
Date: Fri, May 25 2018 5:41PM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
> Birkir, just to clarify, your example is good when you're hiding/unhiding child elements but if the change is just to the text inside the element, then having aria-live on the child is fine.
I have to concur with Birkir, I've seen aria live on the parent required for some browser combinations in the past. ARIA live support is still very temperamental across browsers and screen readers in my experience.
Jonathan
From: glen walker
Date: Sat, May 26 2018 8:22AM
Subject: Re: forms and multiple aria-live regions
← Previous message | Next message →
All testing I've done on current browser/AT combinations have not had any
problems with aria-live on the child so perhaps this has gotten better, but
that was with text changes, not with hiding/unhiding child elements.
That's why I qualified my previous comment.
Glen
On Fri, May 25, 2018 at 5:41 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:
> > Birkir, just to clarify, your example is good when you're
> hiding/unhiding child elements but if the change is just to the text inside
> the element, then having aria-live on the child is fine.
>
> I have to concur with Birkir, I've seen aria live on the parent required
> for some browser combinations in the past. ARIA live support is still very
> temperamental across browsers and screen readers in my experience.
>
> Jonathan
>
From: Birkir R. Gunnarsson
Date: Sat, May 26 2018 10:14AM
Subject: Re: forms and multiple aria-live regions
← Previous message | No next message
I concur with Glen
If you are inserting or updating textinside a live region element it
works pretty well, just see the live region playground over on the
public examples page on Deque University (I developed that example
with Harris schneiderman 4-ish years ago).
But if you simply change the display state of a live region element
directly it is generally not announced by a screen reader, but if you
put the live region attribute on its parent it is (not as consistently
as injecting text with Javascript but decently).
On 5/26/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> All testing I've done on current browser/AT combinations have not had any
> problems with aria-live on the child so perhaps this has gotten better, but
> that was with text changes, not with hiding/unhiding child elements.
> That's why I qualified my previous comment.
>
> Glen
>
>
> On Fri, May 25, 2018 at 5:41 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> > Birkir, just to clarify, your example is good when you're
>> hiding/unhiding child elements but if the change is just to the text
>> inside
>> the element, then having aria-live on the child is fine.
>>
>> I have to concur with Birkir, I've seen aria live on the parent required
>> for some browser combinations in the past. ARIA live support is still
>> very
>> temperamental across browsers and screen readers in my experience.
>>
>> Jonathan
>>
> > > > >
--
Work hard. Have fun. Make history.