How do you notify AT users of error messages?

Accessibility
1

A couple of questions for you.

It occurred to me that the standard practice of re-displaying a form with error messages might not be obvious to screen reader users. How do screen readers handle a page that reloads? I have not experience of this. Is the change unknown until the software reaches the error messages as it re-reads the page?

I found an article at the Web Standards Project website that mentioned that the page title should change, which sort of makes sense. I had completely overlooked that possibility. I managed to work out a way of doing that, but what methods do you use in this situation? Any tips?

Just looking to make things easy and efficient for all users, with a minimum of hassle for them.

2

Yes, good questions, which I am also asking at the moment. My current feeling is that the page title should be something like “Error”, followed by a list of the errors. I’m also playing with each error message having a link to the relevant input. However, I’m not sure how easy it would be to find one’s way back to the error list after fixing the first problem. So it’s also worth adding some kind of error message to each label where a mistake was made, so that the user can move through the form normally and understand where the errors are that way. If there’s something like a password field that needs to be re-typed, that should be indicated also.

3

I’m also playing with each error message having a link to the relevant input. However, I’m not sure how easy it would be to find one’s way back to the error list after fixing the first problem.

Yeah, that is an interesting possibility. Obviously, that would place an entry in the browser history (in browsers that I use, anyway) that reflects the change, but I don’t know how screen readers handle in-page links (for want of a better description). I feel like it might just over-complicate things a bit, and be a bit more of a hindrance than a help.

I’ve placed my error messages in an OL above the form, with a parent message that changes to reflect the number of errors: either “you have one error that needs your attention” or “you have x errors that need your attention”. Might tweak the phrasing a bit. My rationale for placing them together above the form is what someone, probably Stomme poes, mentioned about screen readers in “form mode” skipping non-form elements. I can’t test that, though. And it seems to suit a short form.

4

Yeah, same here. I actually posted a thread about it yesterday. I’ve been finding them buggy in Apple’s VoiceOver, and wondered if other screen readers have a problem with them.

My rationale for placing them together above the form is what someone, probably Stomme poes, mentioned about screen readers in “form mode” skipping non-form elements. I can’t test that, though. And it seems to suit a short form.

Yes, although she has spoken elsewhere of maybe having inline error messages too. You can make the message part of the input’s label. That would be my approach, anyhow.

5

If it’s part of the label, that would need some tricky CSS positioning wouldn’t it?

6

No, I meant having a list of error messages at the top of the page, but the error message repeated in the actual label associated with the form control.

7

Like adh32, I use a list of links above the form (since the user hit the submit button, a new page was loaded… that’s always announced to users) which go to the error message in question (which is an anchor with no destination actually). I’m using aria-describedby to associate the error message with the label.
(of course the error page has the page <title> saying the form was not submitted, the h1 states there were errors, etc.)

Originally my form idea was, a (invisible) anchor was generated after each “bad” input that could take the user to the next error message (or submit if there are no others) but the back-ender said it was too difficult to bother. on :focus of these invisible anchors, they’d appear so this would also kick butt for sighted-keyboarders too. Would have loved to see that working somewhere : (

Users, if advanced, can use shift-L or whatever for “previous list” to get back to the list, but I wouldn’t know if newbies would try this.

Error messages as plain text in a form: some screen readers have a Forms mode, but not all. In Forms Mode, only form controls are read out (when you focus on an input, the associated label and possibly the legend are read out, for example). However I’ve found that even when in Forms Mode in, say, JAWS, if there’s other focusable thingies in there (like anchors), those’ll be read out fine, because they have keyboard focus and you can’t just ignore those. One reason I made my errors anchors: they were focusable destinations and their anchor text was the error text.

NVDA is really great in Forms because it switches easily and usually automatically between forms mode (which tells you an input is editable and reads back what you type when typing into one) and regular reading mode (whenever it finds plain text, it’ll switch… meaning when you hit keys, they’ve gone back to navigation keys instead of typing keys). This is really nice and JAWS seems clunkier because you usually have to manually move in and out of Forms Mode. But this is version 10 I have, 12 is out and maybe is more intuitive? But version 10 does do aria-describedby so that’s nice.

Orca doesn’t have a virtual buffer and doesn’t have a forms mode that’s particularly special: like NVDA it seems to just switch between reading and letting you Edit, but I haven’t gotten the hang of getting those to work right… all playing around with the Orca button or something…

Re virtual buffers: if you’re using AJAX to report errors, you have to be much more careful. Older readers with virtual buffers (JAWS, Window-Eyes, NVDA for Windows all have virtual buffers) may not know to refresh them just because there was some AJAX call. Newer readers do know, but you’ll want to use some of the other ARIA attributes to have the new error messages interrupt the user or move the focus over to the error message or something.

Unfortunately I don’t do enough AJAXY widget stuff to be familiar with all the ARIA-stuff out there for this kind of thing, and support is kinda here and there (newest readers are doing pretty good with ARIA… you can keep up with ARIA tests by Jason Kiss at Accessible Culture.org).

8

I’m using aria-describedby to associate the error message with the label.

That’s a good suggestion. I hadn’t thought of that, even though I have added it to the form elements.

Actually, I’ve struggled to find any in-depth articles about the different groups of ARIA attributes and what they could be used for: there’s plenty of simple introductory articles about the role attributes, but little else.

9

Marco Zehe’s “Easy ARIA tips” are pretty good in giving you an idea on how to use some specific aria attributes… just don’t use any of the rest of the HTML, it’s often invalid. Just see how he uses the attribute.
Tip #1: aria-required (I’ll combine this with a star + text at beginning of form as well, or title=“required” or something… I don’t rely on aria)
Tip #2: aria-labelledby and aria-describedby Note the spelling. Some browsers were accepting labeledby I believe, but stick to official spellings.
Tip #3: aria-invalid and the alert role Here he uses Javascript validation onblur, but you could just as easily have your back-end add in the same text with the same roles/attributes as well. I would really love to try these ones out… but helaas, I’m not a back-end programmer : (
This is almost a reason for me to get going on that area : )

He’s got some more, but these ones were quite form-specific. : )