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

Move the aria-expanded attribute to the correct element #238

Merged
merged 5 commits into from
Jul 16, 2021

Conversation

colinbm
Copy link
Contributor

@colinbm colinbm commented Jun 21, 2021

⚠️ Don't forget to update the gem version in the CHANGELOG before merging! When you're ready to release bump version file and generate a tag. ⚠️

What

  • Move the aria-expanded attribute onto the toggle button

Why

From the DAC review:

There are sections of content with Show/ Hide functionality. Neither the expandable behaviour of the control nor its expanded or collapsed state are programmatically determinable as the aria-expanded attribute has not been utilised (please note, it appears this attribute has been incorrectly associated with the expandable region rather than the trigger).

@36degrees
Copy link
Contributor

Whilst looking at this, I spotted an issue with the nav list that I've also fixed... currently we have too many ul elements. We should only have these at the open/close of the nav, and at the open/close of each new level of nav. As it is we have a ul element for each li.

I'm not sure this change is quite right – now everything in the nav sits at the same level.

On the current version in master, the nav looks like this:

Screenshot 2021-06-22 at 09 41 53

On this branch, it looks like this:

Screenshot 2021-06-22 at 09 42 35

@colinbm
Copy link
Contributor Author

colinbm commented Jun 22, 2021

Odd - it's not doing that on mine - investigating.

@36degrees
Copy link
Contributor

Can we consider splitting the list structure changes into a separate PR? As I understand it, they're unrelated to the aria-expanded change which looks good to go?

isOpen was initially set, to the *current* state. Subsequent controls
were inverting that. If we invert it at the beginning this becomes clearer
Note - also renamed to setOpen to signify intent.
@colinbm colinbm force-pushed the accessibility-aria-expanded branch from 85257e9 to 4ba92c8 Compare June 23, 2021 11:21
@colinbm
Copy link
Contributor Author

colinbm commented Jun 24, 2021

@36degrees seperated that off

@36degrees
Copy link
Contributor

36degrees commented Jun 24, 2021

Thanks @colinbm! Would you mind tidying up the PR description to remove the changes that have been split out?

Unfortunately, there's another place in the code where aria-expanded is being set which needs fixing too. When the code is first initialised, aria-expanded is still getting set to false on the collapsible__body:

$(this).addClass('collapsible__body')
.attr('id', uniqueId)
.attr('aria-expanded', 'false')

This means that the collapsed state is not announced when you first navigate to a button, only once it's been toggled at least once.

We're also still including a non-sensical aria-expanded on the toggled region, except now it's permanently set to false.

Sorry that I didn't spot that as part of my previous review!

We should really have tests that cover all of this included in /spec/javascripts/collapsible-navigation-spec.js. However, I don't think it's fair to ask you add them as you're only fixing the existing implementation.

@colinbm
Copy link
Contributor Author

colinbm commented Jun 28, 2021

@36degrees Ah, apologies - I had fixed that, but somehow it failed to go into the commit.

Copy link
Contributor

@36degrees 36degrees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

@colinbm colinbm changed the title Accessibility aria expanded Move the aria-expanded attribute to the correct element Jul 13, 2021
@colinbm colinbm merged commit 4024720 into master Jul 16, 2021
@colinbm colinbm deleted the accessibility-aria-expanded branch July 16, 2021 12:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants