Resource Create/Edit - Githubissues

For compliance with Web Content Accessibility Guidelines (WCAG)

Labels for form fields, buttons, and button-like (scripted) elements: The "Content" main field needs a real tag associated with it.

The show/hide widget above the right of the Content textarea and to the right of the tabs (Document, Settings, Template Variables...) needs a label. Give it a label like "hide Content field" (for the bottom one) or "Hide page properties" (for the top one), which should toggle to "show Content field" after it has been activated. This should probably be a button, so it could be coded like this:

In some ways it would be preferable to have real text in the button:

This text could be visually hidden using CSS clip or offscreen techniques (don't use display:none, because that hides it from screen readers too!).

In the "Template Variables" pane, when a template variable has a property like @INHERIT, the text that currently shows up to the right of the field (e.g. "Value Inherited") needs to be inside the . You can still style it to be over on the right side, but don't put it outside the label.

Required fields: Use aria-required="true" on all required elements. Screen readers will say "required" when reading to users.

Keyboard accessibility: The tab interface is not keyboard-accessible. Users need to be able to navigate to the tab list with the tab key, then use the arrow keys to navigate the tabs themselves. See https://dequeuniversity.com/assets/js/aria/saveform/form2.html for an example of an accessible tablist and tabpanel.

The "Uses template" selector:

Ensure this widget is fully keyboard accessible so that people using only the keyboard can switch templates.

The Content show/hide widget:

Ensure keyboard users can tab this control

The scripted read-only inputs under the "Settings" tab:

The button (and it should be a button) to the right of the "Parent Resource" field needs to be keyboard-accessible, and/or users need to be able to type an integer directly into the field.

The button to the right of the "Resource Type" field needs to be keyboard accessible, and keyboard users need to be able to select a resource type without a mouse.

The button to the right of "Content Type" needs to be keyboard-accessible and users need to be abel to select a content type without a mouse.

The button to the right of "Content Disposition" needs to be keyboard-accessible and users need to be able to select a content disposition without a mouse.

The "Template Variables" panel:

The tablist on the side must be keyboard accessible. See https://dequeuniversity.com/assets/js/aria/saveform/form2.html for an example of an accessible tablist and tabpanel.

The "Set to default" feature is not keyboard-accessible. Users should be able to tab to it and use it without a mouse. NOTE: Be sure to give each of these a distinct name, so they don't all say just "Set to default". You want it to say something like "Set Course ID to default", where "Course ID" is the name/caption for the template variable. Otherwise users won't know for sure which button refers to which field, because there may be several TVs and the placement of the "Set to default" button could be ambiguous (does it refer to the previous TV or the next TV?).

The resource group panel:

This seems to be unavailable by keyboard, but if you cheat and click with your mouse in the list of resource groups, keyboard access to the pane is possible, even though access to the checkboxes is not.

checkboxes:

The resource group checkboxes are available only with a mouse. They need to be keyboard-focusable and keyboard-functional (with enter or space bar).

Keyboard tab order: For the most part the tab order is good (for the things that can be tabbed to), but the "Freeze URI" checkbox is out of order. It looks like it should be next after "Rich Text" but it is not.

Error messages: When a field is invalid (required field is empty, for example) onblur, add aria-invalid="true" so that screen reader user will hear this when they navigate back to the field.

When the user attempts to submit the page when there are invalid fields, move the keyboard focus to the invalid field (even if that field is in a different tab panel than the current focus), so that users can find the error and fix it. Make sure the error message is associated with the field by either being in the itself or being referred to by aria-labelledby. Here is a suggestion:

Title*
This field is required

When both the label and the error message are wrapped in the label tag along with the input itself, the title and error message with both be read when users focus on the input. This is a very convenient way of ensuring that error messages will be read by screen readers. (Note that aria-invalid="true" applies only after the field is truly invalid; not on page load.)

See accessibility to-do list at https://dequeuniversity.com/modx-accessibility.html#resource

modxcms / a11y

Resource Create/Edit #1