1690122 - Add VoiceOver support for linked header attributes on columns and tables

Status: NEW

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

Description

[Morgan Reschenberg [:morgan]]

STR:

1. Enable VoiceOver
2. Load data:text/html,<table><tr><th>header one</th><th>header two</th></tr><tr><td>cell one</td><td>cell two</td></tr></table>
3. Move VoiceOver focus to cell one by entering the table (VO+Shift+down) and moving past the headers (VO+down)
4. Instruct VoiceOver to read the table row from cell one (VO+R+R)

Expected:
VoiceOver reads "Header one, cell one, Header two, cell two"

Actual:
VoiceOver reads "cell one, cell two"

In order to get the correct utterance, I think we should support NSAccessibilityHeaderAttribtue (AXHeader) on both columns and tables, as webkit seems to do.

If you're interested in contributing to this good-first-bug please need-info me! I'm happy to mentor :)

Comment 1

[saffafatima12]

Hi, I am new to the FireFox community. I am really interested in contributing to this good-first-bug, and would love to find out more about it :)

Comment 2

[Morgan Reschenberg [:morgan]]

(In reply to saffafatima12 from comment #1)

Hi, I am new to the FireFox community. I am really interested in contributing to this good-first-bug, and would love to find out more about it :)

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 :) ). For this bug, you'll need a build for Firefox Desktop (NOT the artifact version, the regular one!). This bug is only reproducable on Mac, so if you'd like to test locally you'll need to use MacOS natively or on a virtual machine. If you don't have access to either, you can still tackle this bug with the help of our try server.

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!

Comment 3

[Morgan Reschenberg [:morgan]]

Once you've got a build set up, here are some things to start poking at:

• 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 (accessibility) 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/. For this bug you should only need to modify files in that folder. The files are organised according to our project architecture, which you can read more about on our wiki page. Don't worry about committing it to memory, just know this page exists and is a good first-resource for questions as they come up!

• 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 kind of mac accessible for the given core accessible. You can see how this mapping works here.

• For this bug, we're interested in table accessibles and table cell 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 (its firefox google!). 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 use comments to 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.

• For this bug, we'd like to implement a new attribute: AXHeader . This attr should map to a function in the same way AXRole maps to moxRole. You'll need to modify MOXAccessibleProtocol.h to create this mapping, and then you'll also need to modify the table accessible and column container classes to show VoiceOver that the attribute is supported for those types (make sure to modofiy both the header and objcpp file).

• So, what does this attribute do? In an HTML table, a web author can specify table headers with the <th> tag. When VoiceOver reads the information in a column, it should also read the associated header to provide an AT user with appropriate context (see the example in comment 0). VoiceOver expects the header for a column to be stored in AXHeader, it also expects the header group (so, the row containing the table header) to be stored in the table's AXHeader attribute. Note, we should be returning a single object here -- either the row accessible that holds our headers if we are a table, or the cell that holds our header if we are a column. This means our return type for our function should be id.

• We already support similar attributes for getting the column headers (moxColumnHeaderUIElements) and row headers (moxRowHeaderUIElements) for both a table and for a cell. Both of these functions traverse the core tree to find the header accessibles, and then get their native (mac) representation by calling ToNSArray. For your implementation, you shouldn't need to traverse the core tree -- can you find a way to use these existing functions in your new moxHeader implementation? (Note that these functions each return an NSArray, but you'll need to return a single ID)

• 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_table.js which contains other tests for table and table-part accessibles. Your test should do the following:
  -- Launch a page containing a table with both data cells and headers
  -- Get the table's native accessible, and query its AXHeader attribute
  -- Verify that the header attribute is what you expect
  -- Get the container for a particular table column, and query its AXHeader attribute
  -- Verify that the header attribute is what you expect

If you search around for mac tests that use .getAttributeValue, you should be able to find some relevant examples of tests that already do something similar :) The tests in that table test file are a good place to look, too.

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. 🎉

Comment 4

[saffafatima12]

Thank you so much for all the detailed information. It is extremely helpful :) I don't have access to a Mac, therefore I decided to set up Virtual Box running MacOS on my Windows System. However, I am facing some issues in connecting to the internet from my virtual machine. I will try my best to resolve these issues as soon as possible. I have not worked with accessibility trees before, and I think it will take me some time to learn enough about them to be able to tackle the bug. Is it okay if I take a few days? or does this issue needs to be solved quickly? Thanks once again for your quick response and sharing such detailed and useful information :)

Comment 5

[Morgan Reschenberg [:morgan]]

No problem, take all the time you need :) This issue is in our backlog, which means we'd like to have it fixed eventually, but we don't need it to be fixed by any particular time. When you look at bugs on bugzilla, you'll see they have both a severity field (S3 in this case) and a priority field (P3 here). Severity refers to how many users are impacted by this bug, or how unusable it makes the product. Generally, we rank severity on a scale of 1-4, with 1 being "really really severe", and priority is ranked 1-3 with 1 being "needs to be fixed in this next release". This bug is on the low end of both categories, so it isn't pressing.

With respect to the virtual machine stuff, its totally okay if you'd rather develop natively! Building in a virtual machine can be a bit slow, and while its useful to have a platform to test locally, we can always use the try server to test things across platforms :) If you want to go that route (which I'd suggest, especially if you're going to contribute to other non-mac-specific parts of mozilla in the future), I'd start by writing that browser test that I talk about at the end of my previous comment -- that way, we can push the test to try, make sure it fails, have you write a patch, push again, and check for success.

Comment 6

[saffafatima12]

I am glad to know that I can take more time to learn about and solve this issue.

I was also quite worried about building in the VM because it was quite slow and I don't think my computer hardware could have supported building an entire Firefox Desktop in a VM. Thank you for suggesting to develop natively and then testing on try server.

I built the regular version of Firefox Desktop yesterday on my Windows. There were some issues, mostly due to my poor internet connection, but I am happy that it is up and running now. I have started to look through the code and have taken a brief look at the files you mentioned in your earlier messages. I will attempt to write the browser test soon and will let you know :)

I have also set up a Matrix account and sent you an invite because I think it will be easier to ask any questions (which I expect I will have lots soon) there.

Comment 7

[saffafatima12]

Attachment: Bug 1690122: Added AXHeader for table & column

Bug 1690122: Added AXHeader for table & column

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.