Ensure dashes not read in screenreaders #3122
Conversation
beccapearce
force-pushed
the
ensure-dashes-not-read-in-screenreaders
branch
from
de66c82 to
184adea
Compare
beccapearce
force-pushed
the
ensure-dashes-not-read-in-screenreaders
branch
from
184adea to
e4b7abb
Compare
| @@ -8,7 +8,7 @@ def body | |||
|
|
|||
| def header_links | |||
| header_links = details.fetch("header_links", {}) | |||
| Array(header_links).map { |h| ActiveSupport::HashWithIndifferentAccess.new(h) } | |||
| Array(header_links).map { |h| ActiveSupport::HashWithIndifferentAccess.new(h.transform_keys { |k| k == "title" ? "text" : k }) } | |||
There was a problem hiding this comment.
I don't think this is the best way of doing this, very open to suggestions that make it clearer, or I can add some comments
|
This looks great to me. 👍 Nice to see a bunch of stuff removed as part of the work. |
|
Yes! Martin and I took a look at the tracking and we think it looked ok when we tested it on integration |
OK, I suspect that's just a function of using the component then. The other thing (sorry!) is that it does create a fairly different experience for the user: where it used to retain the list of links in view and scroll the content to it, we now have standard skip links. Should we (or maybe we have) consult with someone on the design side about this? Maybe we'd need to introduce some kind of "back to top" mechanism or some-such. I tend to think that using the component makes for a more consistent experience across all parts of the site but it's quite a big change. (I'm sure we can live with the change from en dash to em dash) |
|
AH no I don't think we have checked with design, I can do that! |
beccapearce
force-pushed
the
ensure-dashes-not-read-in-screenreaders
branch
from
e4b7abb to
a4557fc
Compare
|
@beccapearce Nice work on this and removing the bespoke CSS and JavaScript. I had a further look at the GA events firing after switching to the When comparing the difference for the - Event Data (section): Page contents:
+ Event Data (section): ContentsThe only other change that I could see relating to Google Analytics events, is that using the @andysellick @AshGDS sorry to tag you in directly, just want to double-check my understanding here and if there is anything I may be overlooking relating to Google Analytics with this change? thanks |
|
Thanks for asking about this @MartinJJones.
Using the contents list component means that tracking will happen automatically (it's build into the component). You're right, the GA4 stuff probably won't fire on Heroku so checking it on integration is a good idea. If you type
Realistically Universal Analytics is going to stop working at the end of June anyway so it's probably not something to be overly concerned about. |
|
Thanks for the further info @andysellick 👍 |
When the contents list on service manual guides was being read out by screen readers it would read the dashes in the contents list as "en dash" This was not desired behaviour and has been fixed in the govuk-publishing-components. This uses the fixed publishing component to take advantage of the fixed behaviour. Using the new publishing component also makes the page more consistent with other pages within the app.
In the previous commit we changed the contents list on the service service_manual_guide page to use the publishing component. This means that we are now able to delete the custom styles and javascript that were being used previously.
beccapearce
force-pushed
the
ensure-dashes-not-read-in-screenreaders
branch
from
a4557fc to
271654f
Compare
Add a margin to the top of the contents list on service manual guides so it isn't too high up the page when scrolling
|
While completing this work, we noticed that the functionality in the sticky module is similar to that used by html publications' content lists Ideally we could combine the two into one place to tidy up the code and reduce duplication. We should complete this work as a separate PR since it may cause some changes that should be discussed separately. |
Nearly every screen reader (except NVDA of the major ones) reads out the “en dash“ (VoiceOver on macOS says “space“) before each item/link in the “Page contents“ list. Screen reader users found that frustrating to read through.
To solve this we have used a version of the contents list in the publishing components which fixes this issue. This has also meant that we have removed some of the custom elements that were applying to the contents list in favour of the standard govuk-publishing-components. This means that there is a change in the appearance of the contents due to this.
Before:
contents_list_old.mov
After:
Screen.Recording.2024-04-05.at.13.18.54.mov
Trello card: https://trello.com/c/prtvfJV5