Skip to content

WIP: Fix and improve accessibility of sign-in/sign-up tabbed interface

Boris Dušek requested to merge dusek/gitlab-ce:a11y-sign-in-up into master

What does this MR do?

This MR improves screen reader user experience of the sign in and sign up interface:

  • selected and not selected tabs are now properly announced
  • the shown "panel" (e.g. the panel with "Username or email" and "Password" fields and "Sign in" button) is now reported as labeled by the relevant tab title (e.g. "Sign in") when entering it
  • the "tabs area" for selecting the pane (i.e. the whole area containing "Sign in", "Register" and potentially "LDAP" tabs) is now reported as "Authentication"

This is a result of following the guidance of the 3.21 Tabs section in WAI-ARIA Authoring practices, specifically only its "WAI-ARIA Roles, States, and Properties" part. The "Keyboard Interaction" part has yet to be implemented.

This is my first MR to Gitlab, so please have a little bit patience with me :-).

Manual Testing

I tested this thoroughly with (this is where all the improvements take effect):

  • VoiceOver/Safari: VoiceOver on macOS 10.14.2 (18C54) with latest Safari (12.0.2 (14606.3.4))
  • NVDA/Firefox: NVDA 2018.4 with latest Firefox (64.0) on Windows 10 (Version 10.0.17134 Build 17134) which I think is the most reasonable browser to use with NVDA

I also tested briefly with (this was tested mainly to make sure nothing breaks in general; only some improvements):

  • VoiceOver/Chrome: Chrome (71.0.3578.98 (Official Build) (64-bit)) on the same macOS with VoiceOver (same as with Safari/VoiceOver
  • NVDA/IE11: Internet Explorer 11 (11.472.17134.0, Update version: 11.0.101) on the same Windows with same NVDA (bad experience in the tabs area - does not read the tab that is selected at all, does not even work in the Example of Tabs with Manual Activation linked from the guide above)
  • NVDA/Edge: Edge (42.17134.1.0, EdgeHTML 17.17134) on the same Windows with same NVDA (similar to improvements with Firefox/NVDA but does not read position of the tabs (e.g. "1 of 2") and does not announce “Authentication tab control”)

I did not test with the JAWS screen reader on Windows since I do not have a license for it and its license even explicitly forbids using it for accessibility testing in the free 40-minute demo mode. That is a pity, since apart from the Firefox/NVDA combo I would consider the JAWS/IE combo the second "flagship" Windows screen reader browser combo to test.

I also tested with enabled LDAP so that 3 tabs were present ("LDAP", "Sign in", "Register").

Discussion

It seems that all of the accessibility implemented here and more (i.e. the keyboard part in the WAI-ARIA Authoring practices - see above) could be gotten for "free" (and not have to be implemented here) if Paypal's Bootstrap accessibility plugin (implemented for Bootstrap 3) would either be merged into Bootstrap 4 (see specifically that plugin's support for tabs) or would at least be usable with Boostrap 4 so that Gitlab could use it (preferably having some way to opt-in or opt-out of its behavior to have things under control).

I named the "tabs area" (the container containing the "Sign in", "Register" and potentially also "LDAP" etc. tabs) as "Authentication". I am open to suggestions on naming it better (e.g. "Sesssions"?), since I was not clear what is the best name anyway.

I did not add tests, because honestly the whole situation around frontend tests seemed a bit overwhelming (many new things for me). However I would be happy to add tests with a little bit of guidance. I tried creating something in spec/views/devise/sessions/new.html.haml_spec.rb following the example of spec/views/devise/shared/_signin_box.html.haml_spec.rb and succeeded checking that the page has a link with title "Sign in", but could not find a way to check that it has role tab, to check that its aria-selected=true (and same for the "Register" tab except checking it has aria-selected=true), to get its id, maybe to get its href, to get its aria-controls, to get the element pointed to by its aria-controls, to check that that element’s aria-labelledby attribute is the same as the link’s id attribute; then to click e.g. the "Register" link and check the aria-selected attributes got properly changed on all tabs. I basically got as far as trying:

expect(rendered).to have_link('Sign in') { |a| a['aria-selected'] == true }

but that results in a stack overflow :-).

The videos were taken at the end of September 2018 with slightly older macOS, Firefox and NVDA versions; however the behavior seems to be the same as with the most up-to-date versions of everything with which I tested today.

Marking this MR initially as WIP due to all points raised in this "Discussion" section.

Demonstration of improvement

NVDA

Tabbing is used here to navigate elements in NVDA.

Before

  • when the tabs area was entered, it was announced just as "tab control", giving no closer advance hint what is its purpose
  • both "Sign in" and "Register" tabs were announced as selected, even though only the "Sign in" tab is
  • when tabbing from the tabs area (the "Register" tab in it) to the currently selected panel (specifically its first element, the "Username or email" field), it was not announced that such a transition (tabs area -> panel) occurred (i.e. creating a "soup of elements" blended together, unlike what is presented visually)

A11Y_AuthTabs_Before_NVDA

After

  • "Authentication tab control" is announced when entering the tabs area
  • only the "Sign in" tab is announced as selected (as is correct)
  • when tabbing from the tabs area (the "Register" tab in it) to the currently selected panel (specifically its first element, the "Username or email" field), NVDA announces "Sign in property page" before reading "Username or email", giving the user better idea they entered a new area and which one is that (basically separating the tabs area from the pane, like it is done visually)

A11Y_AuthTabs_After_NVDA

VoiceOver

VO-left/right is used here to navigate elements.

Before

  • when the tabs area was entered, it was not announced at all, not hinting the user they are entering a semantically new area (such hints are communicated in the graphical interface)
  • no tab was announced as "selected", even though "Sign in" tab is selected
  • when moving (with VO-right arrow) from the tabs area (the "Register" tab in it) to the currently selected panel (specifically its first element, the "Username or email" field), it was not announced that such a transition (tabs area -> panel) occurred (i.e. creating a "soup of elements" blended together, unlike what is presented visually)
  • similarly when moving out of the panel to further area (i.e. past the "Sign in" button), no hint was given the panel has been left

A11Y_AuthTabs_Before_VO

After

  • "Authentication tab group" is announced when entering and leaving the tabs area
  • the "Sign in" tab is announced as selected
  • when moving (with VO-right arrow) from the tabs area (the "Register" tab in it) to the currently selected panel (specifically its first element, the "Username or email" field), "Sign in, tab panel" is announced, similarly when moving past the end of the panel and back

A11Y_AuthTabs_After_VO

After 2

Same as "After", just demoing the change in tab panel name ("Sign in, tab panel" → "Register, tab panel") after selecting a different ("Register") tab.

A11Y_AuthTabs_TabPanelName_After_VO

What are the relevant issue numbers?

None

Does this MR meet the acceptance criteria?

Edited by Boris Dušek

Merge request reports