Focus does not jump to form errors

Great catch, thank you swirt! I wonder if this needs to be done for D8 as well.

It looks like in D8 there is a message at the top with links down the page to the errors. It's not quite the same as automatically focusing on the errors, but I'm thinking we might just leave it as-is for now.

re #6 -

It looks like in D8 there is a message at the top with links down the page to the errors.

That block of error links comes from the Inline Form Errors module. It's our implementation of G139: Creating a mechanism that allows users to jump to errors (example 1). It's described as an "additional, advisory" technique for WCAG SC 3.3.1 Error Identification and SC 3.3.3 Error Suggestion. Note this module isn't yet enabled by default in the Standard input profile, but we're intending to do that in #2915899: [PP-1] Enable the Inline Form Errors module in the Standard install profile.

Also re: #6,

It's not quite the same as automatically focusing on the errors, but I'm thinking we might just leave it as-is for now.

Indeed, focusing the error message is an alternative approach for the same WCAG success criteria. The list of error jump-links is good for forms which can have multiple errors on them (e.g. address, email, phone all required).

An approach that could work in D8 is to move focus to the message block, regardless of wheter Inline Form Errors is enabled.

Keep in mind that it's an optional module, but either way there will usually be a red error message block. The only difference is whether the block contains the entire list of error messages, or just links to the form inputs with error messages inline.

The D8 API also has a feature to disable the Inline Form Errors behaviour on a per-form basis. See Inline Form Errors can be disabled for the complete form.

Nice, thanks for the context Andrew. To add a bit more about this theme - the D7 version has custom code that implements the inline form errors, while the D8 version relies on the core Inline Form Errors module that Andrew mentions.

Which part of section 508 requires focus to change to the form error? I don't think WCAG requires this.

@swirt - Thanks. I meant, specifically, does something in section 508 require focus to be set, rather than WCAG? I was curious whether section 508 was putting this requirement on top of WCAG. In which case, this USWDS theme is an ideal place to address it. The Drupal core accessibility QA gate doesn't aim to address local standards like section 508, just the W3C recommendations.

I'm aware of the techniques and issues. None of those WCAG success criteria actually require focus to be changed (or even to use scripting at all). Setting focus to an error message is just one available approach.

In G139, moving focus is mentioned in example 3. The error links provided by Drupal 8's inline form errors module actually implement example 1 there. Example 3 is along the same lines as you suggest in comment #10. It would be OK to add that on top of what Drupal core already provides.

G139 example 3 also has this interesting bit:

And there is a link from the error back to the ordered list of descriptive error messages.

That's do-able too, with a hook_form_alter() to put a "back to error list" link after each input.

I've been thinking of putting together a contrib module, to present some of these focus behaviours and extra links as easy options for site-builders to enable.

Fair enough. Maybe the reviewer said you should do this, because it would be a straight forward thing to implement.

I might have been getting confused between the revised section 508 itself, and IBM's accessibility checklist for addressing section 508. That checklist has a section for european EN 301 549 (Europe) Additional Requirements which aren't covered by section 508. Somewhere along the way I ended up with the impression that section 508 had extra requirements on top of WCAG.