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

Focus indicator is potentially confusing for tabs and accordion components #1405

Closed
NickColley opened this issue May 31, 2019 · 3 comments
Closed
Assignees
Labels
accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 ⚠️ high priority Used by the team when triaging

Comments

@NickColley
Copy link
Contributor

This issue is from a May 2019 external accessibility audit report.

WCAG Reference: Usability feedback only, there is no WCAG related guidelines.
Issue ID: DAC_Issue21
URLs:

Screen Shots


The focus indicator did not surround elements as expected and only appeared at the top edge of the tab. This was confusing to keyboard only users in some cases as it was not clear which element was in focus.

Current Code Ref(s)

.js-enabled .govuk-tabs__tab--selected:focus, .js-enabled .govuk-tabs__tab--selected.\:focus { box-shadow: inset 0 4px 0 0 #ffdd00, inset 0 8px 0 0 #0b0c0c;

Keyboard only comments

“The highlighting being used on the tabs consists of a line appearing above it. A keyboard only user would expect highlighting to appear around the whole element.”

“After the ‘click to expand link’ was selected, focus went to the line above it. At this point it is not obvious when the line was selected and that it will close the ‘click to expand’ element. As it appeared at the top of the link, I was not sure which link it was highlighting.”

Solution

It is recommended that the entire area receives a visual focus indication, to ensure that it is clear which element is active.

@NickColley NickColley added accessibility awaiting triage Needs triaging by team audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 labels May 31, 2019
@NickColley
Copy link
Contributor Author

@dashouse has considered this feedback and created an example that would address these concerns, he is going to explore this further and based on that we'll make a decision on feedback.

@NickColley NickColley removed the awaiting triage Needs triaging by team label Jun 4, 2019
@NickColley
Copy link
Contributor Author

Dave has explored this in #1394 and we have decided as a team to go ahead with this simplification which will resolve this issue.

@aliuk2012
Copy link
Contributor

Fixed in #1424

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 ⚠️ high priority Used by the team when triaging
Projects
None yet
Development

No branches or pull requests

3 participants