1752054 - Implement support for RADIO_MENU_ITEM and CHECK_MENU_ITEM on MacOS

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[Morgan Reschenberg [:morgan]]

We don't currently support these role on mac, which means we're not serving any state associated with the control, like checked. We should fix that :)

Marking as good-first-bug for someone interested in working on platform stuff -- you'd be writing objective c++ for this (but you don't need to know the language to do it, if you're willing to learn :) ) Ideally this work would be done on/with access to a mac for local testing.

ni?me for mentorship

Comment 1

[Daniel Dafoe]

Hi there! Web developer here with a passion for creating accessible and inclusive experiences. I haven't contributed to the platform before, but I'm always been curious about it and since this is a win for accessibility, I'd love to help out. :)

Let me know how I can get started!

Comment 2

[Daniel Dafoe]

Update: I'm all set up locally with Firefox. I just wanted to wait for this current step of choosing which version of Firefox I want to build. Which should I choose?

Comment 3

[Marco Zehe (:MarcoZ)]

You'll want to build against mozilla-central, AKA Nightly. That always has the most recent code that passed all tests and is part of either the last available nightly, or the next one that is going to be built within 12 hours.

Comment 4

[Morgan Reschenberg [:morgan]]

Hi Daniel!

To add to Marco's (excellent) advice above -- you should make sure you're working with a complete firefox build, not an artifact build.
Artifact builds package pre-compiled binaries to decrease your build time. These are helpful if you're working on frontend code, but for this bug in particular you'll need to edit some objective C files so we need a complete copy of the firefox source.

If you have any questions, let me know ! You can "need info" (NI) me by checking the "request information from" box near the comment field on this bug and entering/selecting my name in the input field. NI's help ensure your questions don't get lost among other bug chatter :)
You can also join mozilla's matrix community and chat in real time with myself and other developers -- https://wiki.mozilla.org/Matrix
For this bug in particular, the #Accessibility room is the best place to direct questions.

Comment 5

[Daniel Dafoe]

Thank you to both of you! I've joined Matrix and the recommended #Accessibility room.

I was actually hoping to get some direction on where I might look to begin working on this. I saw this was a good first bug and I was really hoping to get a bit of mentorship/direction on this one since this is my first exposure to this codebase!

Comment 6

[Morgan Reschenberg [:morgan]]

oops didn't mean to undo this flag -- I'll post some getting-started info here later today

Comment 7

[Morgan Reschenberg [:morgan]]

Okay here we go 🎉 bear with me!

First, thanks for contributing to Mozilla! Contributors are a big part of our community and help us live out the Mozilla mission :)
That said, we understand contributing is an entirely volunteer-based commitment; we don't have expectations around you finishing bugs in a particular time-frame (or finishing them at all!). If life happens, that's okay. Feel free to come back to this when you have time. If you've decided you no longer want to work on a bug, you can hit "edit" and remove yourself from the assignee field. This will put the bug back into the wild for other folks to claim. In that same vein -- if you're looking at a bug and think you want to work on it, the first step is assigning it to yourself. It's really frustrating to put a bunch of work into something and then have another person land a patch under your feet because they didn't know you were working on it, too :( which is why I mention this early. I've assigned this bug to you already, so everything should be good in this department.

Mozilla's accessibility team is responsible for maintaining (among other things!) the APIs that allow assistive technologies to communicate with Firefox and the broader web. This bug touches on our Mac API, specifically the API that Apple's built-in screen reader VoiceOver uses. All the code for this API lives in accessible/mac/. You can poke around in this directory locally, or you can view the files on the web via our Searchfox site. I gave some previous contributor guidance for a mac bug here. Give that comment a read, and let me know if you have any questions.

The fourth bullet point in particular will be helpful -- where the linked bug deals with adding a new method, this bug deals with adding a new role mapping to the linked file.

You'll need to figure out:

• Where should the new mapping go?
• We probably need to create a new class for the two roles listed in the bug title. What class should they (each) inherit from?
• What additional methods do we need to expose? Note that Objective C++ only allows for single inheritance, so we can't have RADIO_MENU_ITEM inherit from both RADIOBUTTON and MENU_ITEM, for example. You'll need to see which one of those inheritance structures is more valuable.
• How can we test this new mapping? (the linked comment has some info on testing as well)

Comment 8

[BugBot [:suhaib / :marco]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Comment 9

[Ahmex]

Attachment: .gitconfig

Comment 10

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1752054: Map radio and checkbox menu items to MOX classes for radio buttons and checkboxes r?eeejay

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32722fb2cb53
Map radio and checkbox menu items to MOX classes for radio buttons and checkboxes r=eeejay

Comment 12

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/32722fb2cb53