Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CCX: Accessibility - Schedule Table modification #22

Closed
pwilkins opened this issue Jul 22, 2015 · 1 comment
Closed

CCX: Accessibility - Schedule Table modification #22

pwilkins opened this issue Jul 22, 2015 · 1 comment
Assignees
Labels

Comments

@pwilkins
Copy link

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:

  • 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”.

@pdpinch
Copy link
Member

pdpinch commented Aug 21, 2015

@pdpinch pdpinch closed this as completed Aug 21, 2015
blarghmatey pushed a commit that referenced this issue Sep 11, 2017
Enabled git auto-export upon course publish
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants