1722005 - Stop using "role" attribute for attendee icons.

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, task)

Description

[Henry Wilkes (they/them) [:henry-x]]

This role attribute is used for ARIA.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1722005 - Replace attendee icon "role" attribute name with "attendeerole". r=darktrojan

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9054c137e8fb
Replace attendee icon "role" attribute name with "attendeerole". r=darktrojan

Comment 3

[Geoff Lankow (:darktrojan)]

Looks like you've broken test_invitationutils.js.

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1722005 - Fix misplaced "attendeerole" from 9054c137e8fb. r=darktrojan

Comment 5

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Geoff Lankow (:darktrojan) from comment #3)

Looks like you've broken test_invitationutils.js.

Whoops. I changed one too many "role"s.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ec1d1c8b069b
Fix misplaced "attendeerole" from 9054c137e8fb. r=darktrojan

Comment 7

[Uplift Request]

Should this fix do into TB 91 ESR? There is no indication as to whether this is a user-facing bug, but it looks like it could upset screen readers.

Comment 8

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Uplift Request from comment #7)

Should this fix do into TB 91 ESR? There is no indication as to whether this is a user-facing bug, but it looks like it could upset screen readers.

I'll give some context: the role attribute was previously used in the following ways

<div class="itip-icon" role="REQ-PARTICIPANT" ... ></div>

<img class="role-icon" alt="" role="REQ-PARTICIPANT" ... />

Since the roles were not aria roles, they are not used. The former was shown in the accessibility tree as an empty section, but is successfully removed from the accessibility tree when we use "attendeerole" instead. The latter is the same in the accessibility tree before and after.

Despite it being pretty silent before (junk role attributes were not taken literally by the accessibility tree), I still think it couldn't harm to uplift this fix, especially with Bug 1695039 being uplifted.

Comment 9

[Uplift Request]

If you think it should be backported, I suggest to set "thunderbird_esr91 affected" and request uplift in due course. Backport gets forgotten at times, so it's best to record all the relevant tracking information on the bug.

Comment 10

[Uplift Request]

Excuse the repetition, but it's time to ask for uplift here.

Comment 11

[Uplift Request]

Maybe a misunderstanding? The developer needs to set the approval-comm-esr91? flag on the patch attachment(s). Tracking is mostly for non-fixed bugs.

Comment 12

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Uplift Request from comment #11)

Maybe a misunderstanding? The developer needs to set the approval-comm-esr91? flag on the patch attachment(s). Tracking is mostly for non-fixed bugs.

Thanks, I haven't done a request before. I was looking for a flag, didn't realise it was on the patch

Comment 13

[Henry Wilkes (they/them) [:henry-x]]

Is there some documentation for the approval request fields? I've only been able to find some for firefox https://wiki.mozilla.org/Release_Management/Uplift_rules#Guidelines_on_approval_comments, but the fields are different

Comment 14

[Uplift Request]

The steps are like this: Click in the "Details" next to the attachment.
If you want beta uplift, select approval-comm-beta?. Beta is at 92 now, this landed in 92, so beta uplift isn't required.
If you want ESR uplift, select approval-comm-esr91?. Then you need to fill in the details:
[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky):

In this case something like:

[Approval Request Comment]
Regression caused by (bug #): "role" was always incorrectly used (or is it a regression?)
User impact if declined: Potential problems with screen readers since "role" is an ARIA attribute.
Testing completed (on c-c, etc.): Yes, and has been on beta for a while now.
Risk to taking this patch (and alternatives if risky): Low risk, simple find/replace. Note: Request covers two patches.

Comment 15

[Henry Wilkes (they/them) [:henry-x]]

Comment on attachment 9232822 [details]
Bug 1722005 - Replace attendee icon "role" attribute name with "attendeerole". r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): "role" was always incorrectly used.
User impact if declined: Potential problems with screen readers since "role" is an ARIA attribute.
Testing completed (on c-c, etc.): Yes, and has been on beta for a while now.
Risk to taking this patch (and alternatives if risky): Low risk, simple find/replace. Note: Request covers two patches.

Comment 16

[Henry Wilkes (they/them) [:henry-x]]

Comment on attachment 9234610 [details]
Bug 1722005 - Fix misplaced "attendeerole" from 9054c137e8fb. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): "role" was always incorrectly used.
User impact if declined: Potential problems with screen readers since "role" is an ARIA attribute.
Testing completed (on c-c, etc.): Yes, and has been on beta for a while now.
Risk to taking this patch (and alternatives if risky): Low risk, simple find/replace. Note: Request covers two patches.

Comment 17

[Wayne Mery (:wsmwk)]

Comment on attachment 9234610 [details]
Bug 1722005 - Fix misplaced "attendeerole" from 9054c137e8fb. r=darktrojan

[Triage Comment]
Approved for esr91

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9232822 [details]
Bug 1722005 - Replace attendee icon "role" attribute name with "attendeerole". r=darktrojan

[Triage Comment]
Approved for esr91

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 91.0.3:
https://hg.mozilla.org/releases/comm-esr91/rev/2de1cc2c91d0
https://hg.mozilla.org/releases/comm-esr91/rev/3d4070c87e51