You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, there are some significant issues with the way the Schedule Table is implemented. In summary, there is nothing that programmatically indicates the relationship between the nested table rows. They only appear related visually by their padding-left. Also, the controls to expand/collapse have no accessible text[1] and are not associated with the Section/Subsection/Unit name. All of these objects are conveyed as equal table rows.
ARIA has a concept for this. Controls such as these are typically represented as TREEs. However, a TREE would not be represented as a table. The table here is really just being used as a convenient display mechanism.
The effort required to change this to a proper tree structure would be very great. I am recommending a “hack” solution that should be easier to implement but fully accessible:
Keep the table structure
Add screen reader text[4] that follows each “title” in the Unit column that identifies it as a “Section”, “Subsection”, or “Unit”
Add screen reader text for each toggle control that indicates what clicking it will do (either “Expand” or - “Collapse” this will toggle according to its current state)
Add controls before the table to “Expand All”/“Collapse All”
Add Help Text to date/time picker
The accessibility of the date and time pickers associated with type=“date” and type=“time” input fields is the responsibility of the user agent. Some UAs will allow the user to manually type a date. For this to work though, it has to be in the right format. Suggest adding help text to these form fields which indicates what the acceptable format is e.g. yyyy-mm-dd or 2015–07–17. The current placeholder indicates that yyyy/mm/dd is acceptable. However Firefox and Safari accept the yyyy-mm-dd format. This makes the current placeholder misleading.
Save Changes
After adding a new unit to the schedule, the Save Changes block is added to the DOM. A screen reader user would not know this has happened. Since an action is required (“Save Changes”) it is appropriate to move focus[2] to this new content. Suggest adding a tabindex=“–1” to this div and moving focus() to it. Saving Changes moves the focus back tot he Schedule a Unit div, and I think that is an acceptable workflow.
Other issues
The “Set date” and “Set time” links should really be buttons.
When you click them, focus[2] must be moved to the modal dialog that opens.
Setting the date or time or closing the dialog should return focus to the control that opened it.
The date and time inputs in the dialog box suffer from the same label issues as in “Schedule a Unit” above
Focus must remain trapped in the dialog box until it is closed.
“Remove” links are all identical and provide no context. It would be helpful to add screen reader text that includes the name of the Unit that would be removed.
All of the toggle controls need accessible text.
All icon fonts ) need aria-hidden=“true” added to them[3].
(copied from Mark Sadecki's CCX Accessibility audit - July 17, 2015)
[1] All elements that are focusable/interactive must have accessible text associated with them so that when a screen reader user moves focus to them, they understand what the control does. The toggle arrows used in this table have no text associated with them.
[2] Focus management is a key concept in accessibility. Screen readers only read what is currently in focus at any given time. Whenever content is injected into the DOM, it will not be read by the screen reader. If the content is meant to be interacted with, you must move focus to the content that was injected so that the screen reader user can progress through the expected workflow as naturally (or logically) as a mouse user would.
[3] Screen readers are not exclusively used by blind individuals. Many people with cognitive or reading impairments use screen readers as well. Text that is spoken is often displayed visually in a uniform font/style. Icon fonts will be displayed as a generic glyph. at edX, we hide these from visual screen readers with aria-hidden=“true”.
The text was updated successfully, but these errors were encountered:
Schedule Table
Unfortunately, there are some significant issues with the way the Schedule Table is implemented. In summary, there is nothing that programmatically indicates the relationship between the nested table rows. They only appear related visually by their padding-left. Also, the controls to expand/collapse have no accessible text[1] and are not associated with the Section/Subsection/Unit name. All of these objects are conveyed as equal table rows.
ARIA has a concept for this. Controls such as these are typically represented as TREEs. However, a TREE would not be represented as a table. The table here is really just being used as a convenient display mechanism.
The effort required to change this to a proper tree structure would be very great. I am recommending a “hack” solution that should be easier to implement but fully accessible:
Add Help Text to date/time picker
The accessibility of the date and time pickers associated with type=“date” and type=“time” input fields is the responsibility of the user agent. Some UAs will allow the user to manually type a date. For this to work though, it has to be in the right format. Suggest adding help text to these form fields which indicates what the acceptable format is e.g. yyyy-mm-dd or 2015–07–17. The current placeholder indicates that yyyy/mm/dd is acceptable. However Firefox and Safari accept the yyyy-mm-dd format. This makes the current placeholder misleading.
Save Changes
After adding a new unit to the schedule, the Save Changes block is added to the DOM. A screen reader user would not know this has happened. Since an action is required (“Save Changes”) it is appropriate to move focus[2] to this new content. Suggest adding a tabindex=“–1” to this div and moving focus() to it. Saving Changes moves the focus back tot he Schedule a Unit div, and I think that is an acceptable workflow.
Other issues
(copied from Mark Sadecki's CCX Accessibility audit - July 17, 2015)
[1] All elements that are focusable/interactive must have accessible text associated with them so that when a screen reader user moves focus to them, they understand what the control does. The toggle arrows used in this table have no text associated with them.
[2] Focus management is a key concept in accessibility. Screen readers only read what is currently in focus at any given time. Whenever content is injected into the DOM, it will not be read by the screen reader. If the content is meant to be interacted with, you must move focus to the content that was injected so that the screen reader user can progress through the expected workflow as naturally (or logically) as a mouse user would.
[3] Screen readers are not exclusively used by blind individuals. Many people with cognitive or reading impairments use screen readers as well. Text that is spoken is often displayed visually in a uniform font/style. Icon fonts will be displayed as a generic glyph. at edX, we hide these from visual screen readers with aria-hidden=“true”.
The text was updated successfully, but these errors were encountered: