Update: provide alternative title text override for menu button ARIA label (fixes #214)

[kirsty-hames]

Fixes #214

Update

• Optional titleAriaLabel override provided to be read out by screen readers, instead of title for the menu item button ARIA label. To be used when title contains punctuation or html syntax that shouldn't be read. If titleAriaLabel isn't set, then title is used to label the menu item button as default.

Note, as per the issue comment, I'd initially suggested naming the override property altTitle for consistency with the alternative title created for question feedback. However contentObject altTitle is already supported to provide an on screen alternative title for PLP. As the two use cases would require separate titles, I decided to create an separate property for aria-label only.

Example use case

title: Being ‘on-spec’ (on screen text)
titleAriaLabel: Being on spec (aria-label text with no punctuation, spelt as should be read)

[cahirodoherty-learningpool]

👀

[swashbuck]

👍

@kirsty-hames Looks good! Will need an update to the Box Menu migration scripts. I think that would be a separate ticket since we don't know what the exact release version would be?

[kirsty-hames]

👍

@kirsty-hames Looks good! Will need an update to the Box Menu migration scripts. I think that would be a separate ticket since we don't know what the exact release version would be?

Hi @joe-allen-89, do we have a defined practice for any PRs that require migration scripts?

[oliverfoster]

👍

@kirsty-hames Looks good! Will need an update to the Box Menu migration scripts. I think that would be a separate ticket since we don't know what the exact release version would be?

That's a terrifying (and probably true) comment.

[joe-allen-89]

@kirsty-hames I'm currently looking at github actions to see if there's a way we can automatically raise an issue on the repo if the schema has been updated. Agree with what Brad said, as we don't really know the release version it would be better to have it as a seperate issue/PR (I think)

[oliverfoster]

This sounds problematic. Example:

The schema changes are released on 1.0.0. The automation changes are added to 1.0.1 (or to master without release). When someone installs 1.0.0, the schema will change, but the automation tasks won't exist in that version.

[joe-allen-89]

This sounds problematic. Example:

The schema changes are released on 1.0.0. The automation changes are added to 1.0.1 (or to master without release). When someone installs 1.0.0, the schema will change, but the automation tasks won't exist in that version.

The other option is validation to prevent release if the schema has been updated but migration script hasn't, but will absolutely every schema change require a migration script? Possibly not.

And still leaves us with having to come in and manually update the migration script as we release to ensure the versions are correct though. Hmm, bit more thought needed on that.

[kirsty-hames]

The other option is validation to prevent release if the schema has been updated but migration script hasn't, but will absolutely every schema change require a migration script? Possibly not.

That's a good point. I'm assuming instances where a new property is added that is either optional or a default value is provided, wouldn't require a migration script? If that's the case, do we need to add a migration script here as titleAriaLabel is an optional property?

For PRs that do require a migration script, could this be handled within the same PR but we have two review phases? For example,
1 - 3 reviews for the PR work
2 - migration script added to PR
3 - 3 more reviews required to review the migration script