Closed Bug 1633570 Opened 5 years ago Closed 4 years ago

Make AXValue settable for incrementable types

Categories

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

All
macOS
defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox88 --- fixed

People

(Reporter: morgan, Assigned: christian.m.macy, Mentored)

References

Details

(Keywords: good-first-bug, Whiteboard: [mac2020_1])

Attachments

(1 file)

Steppers and sliders should be able to set their AXValue attributes. See existing test cases here: https://searchfox.org/mozilla-central/rev/158bac3df3a1890da55bdb6ffdaf9a7ffc0bfb0a/accessible/tests/browser/mac/browser_range.js

Severity: normal → S3
Priority: P2 → P3
Assignee: nobody → mreschenberg
Priority: P3 → P2
Keywords: good-first-bug
Priority: P2 → P1
Priority: P1 → P3
Assignee: mreschenberg → nobody

Hi! I'd like to help with this. I'm an OSS newbie and would love help with first steps. This bug was listed as part of Codetribute and this page mentioned mentors who can help would-be contributors get started.

Is someone able to help me in that capacity? I write code for a living, so I'm fairly confident that once I understand how to get started I'll be able to figure it out from there.

Christian

Flags: needinfo?(mreschenberg)

(In reply to christian.m.macy from comment #1)

Hi! I'd like to help with this. I'm an OSS newbie and would love help with first steps. This bug was listed as part of Codetribute and this page mentioned mentors who can help would-be contributors get started.

Is someone able to help me in that capacity? I write code for a living, so I'm fairly confident that once I understand how to get started I'll be able to figure it out from there.

Christian

Hello! We'd love to have your help on this bug :) If you're new to contributing to Mozilla in general, I'd recommend signing up for a Matrix account on our chat server. Once you're there, you can join the #introduction:mozilla.org channel, there's a whole group of people there dedicated to getting your build environment up and running (plus they've got additional new-to-contributing resources you might find helpful :) )

Let me know when you're set up and have a clone of the mozilla repository, I'm happy to help mentor you on this bug once you're ready! I can also be reached on matrix @morgan if that's easier. Welcome welcome!

Flags: needinfo?(mreschenberg)
Assignee: nobody → christian.m.macy
Mentor: mreschenberg

As promised, here's some starting places for you to start poking at this bug 😀

  • For most bugs in this component, we'll talk in terms of "accessibles" -- an accessible is a node in the accessibility tree. If you're familiar with the DOM, which contains elements, you can think of accessibles as the equivalent object here. They hold information that helps us present content to screen readers and other accessible technologies (AT's). They contain quite a lot of info, but for the purposes of this patch, we'll start by focusing on their roles.

  • The role of a particular accessible helps us determine what actions an AT should be able to perform on the associated element, and what information should be presented to the user about that element. For example, if you have a radio button (role = roles::RADIOBUTTON ) a user should be able to perform a press action, which in return should select or unselect it and report its selected state to the user.

  • To further complicate things, we have a few different versions of the a11y tree; First, we have a "core" tree, which is translated directly from the DOM and contains information that is generally useful to all AT's on all platforms. The code in accessible/base/ and accessible/generic/ help create the core tree. Then, we have individual platform specific trees (ex. the mac a11y tree) which allow us to maintain only information that is relevant for devices supported on that platform. For mac, that means our tree contains info that VoiceOver -- Mac's native screen reader -- expects. Code to create the mac tree is found in accessible/mac/

  • In order to "translate" the core tree into the mac tree, we map accessibles from their core roles (ex. roles::RADIOBUTTON) to their mac role (AXRadioButton), which in turn helps us create an appropriate mac accessible for the core accessible. You can see how this mapping works here.

  • For this bug, we're interested in incrementable accessibles. See if you can find where they live in the mac codebase. If you aren't already familiar with searchfox, its a good tool to use for exploring the firefox codebase. You can find it here.

  • For each mac accessible type, VoiceOver expects us to expose a set of attributes. These attributes are key/value pairs (where key is the attribute name and value is the attribute value) and are how VoiceOver grabs information about the accessible. Here we map the attribute value that VoiceOver uses (ex. AXRole) to the function that we call to retrieve the attribute value (ex. moxrole). These functions are prefixed with "mox", per convention. Note that by default, these attributes are read-only, so VoiceOver can get the value for AXRole, but cannot set it.

  • Some attributes, however, should be settable! Take objects that are selectable, for example. When a user selects them, we should be sure to update the fact that they've been selected (we maintain AXSelected for this purpose). When an attribute is both gettable and settable, we use mox(Attr) as the getter and moxSet(Attr) as the setter. AXSelected for example, has moxSelected and moxSetSelected. Investigate these functions and the associated attribute. Is implementing a moxSet(Attr) function enough to make the attribute settable? What if an attrirbute should only be settable sometimes?

  • For this bug specifically, we'll need to make AXValue settable for mozIncrementableAccessible's! Once you've explored the links above, you should be able to tackle this 😀

  • Once you've made the appropriate changes, you'll need to write a test to verify your work. A11y mac tests live in accessible/tests/browser/mac/ and are prefixed with browser_ to indicate they are browser tests. You shouldn't need to write an entirely new file -- you can add a test to browser_range.js which contains other tests for incrementable accessibles. Your test should do the following:
    -- Launch a page containing an element that will generate a mozIncrementableAccessible
    -- Verify that this accessible has an AXValue, and that it is initially set correctly
    -- Verify that the AXValue attribute for this item is settable
    -- Set the AXValue attribute to a new value
    -- Verify the value is written to AXValue and returns correctly when re-queried

If you search around for mac tests that use .isAttributeSettable, you should be able to find some relevant examples of tests that already do something similar :)

That should about cover it! Please need-info me if you have any other questions, happy to answer them or walk ya through anything unclear. 🎉

Flags: needinfo?(christian.m.macy)
See Also: → 1677915
Attachment #9205230 - Attachment description: Bug 1633570 - Add setter for AXValue (incrementables only) @morgan → Bug 1633570 - Add setter for AXValue (incrementables only) r=morgan
Attachment #9205230 - Attachment description: Bug 1633570 - Add setter for AXValue (incrementables only) r=morgan → Bug 1633570 - Add setter for AXValue (incrementables only) r?morgan
Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/39b030ce1627 Add setter for AXValue (incrementables only) r=morgan
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Flags: needinfo?(christian.m.macy)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: