Hey Yura!

I'd like to work on this bug, could you assign it to me.

(In reply to Bisola Omisore (Sola) from comment #1)

Hey Yura!

I'd like to work on this bug, could you assign it to me.

Sounds good!

Thanks for taking it and please let me know if you have any questions or need some help finding your way around a11y panel code.

Hey Yura,

I have a few questions.

How should we display that information once we have it, maybe name: {value|null} (source attribute) ?

And Is the const { walker } = this.props (line 31) that gets passed to the Accessible Component (line 46) in RightSidebar.js (link below) responsible for the listed properties, and if so where does that data originate from?

https://searchfox.org/mozilla-central/source/devtools/client/accessibility/components/RightSidebar.js

(In reply to Bisola Omisore (Sola) from comment #3)

Hey Yura,

I have a few questions.

How should we display that information once we have it, maybe name: {value|null} (source attribute) ?

And Is the const { walker } = this.props (line 31) that gets passed to the Accessible Component (line 46) in RightSidebar.js (link below) responsible for the listed properties, and if so where does that data originate from?

https://searchfox.org/mozilla-central/source/devtools/client/accessibility/components/RightSidebar.js

Hi Bisola,

All good questions!

In terms of the actual design, we were thinking something like what Chrome currently has for accessible label (see attachment in comment 4). All browsers calculate accessible name/label similarly if not the same and it's based on the spec mentioned in the bug Description.

So what we'd want to do is handle the "name" property in a special way. The row for the name in the Accessible tree would remain the same, and we would add additional children of the "name" row based on the properties that might've affected the name calculation.

So for example, we already have special cases for when we generate props for the Accessible component here: https://searchfox.org/mozilla-central/source/devtools/client/accessibility/components/Accessible.js#438,440,442,474,476 . We would do something similar for when we are processing "name" where we would add new children of the "name" item that are going to be an ordered list of attributes,etc that affect name calculation depending on the DOMNode.

You probably won't need any information from the walker itself, rather you would have to write a new function that generates the children items for the name based on the DOMNode for the current accessible object and the rules that you can reference from https://searchfox.org/mozilla-central/source/accessible/tests/browser/e10s/browser_caching_name.js#29-55. There you will see that depending on a node type, there's a prioritized list of how the name is calculated. It should be sufficient for to start.

Let me know if you want more pointers, etc, this is quite a lot, thanks!

Hey Yura,

I think I got the general gist of it, but could use some more pointers.

Hi Bisola, sure (also if you don't mind, feel free to mark your comment with needinfo flag and my nickname so I don't miss your message).

There are several things that happen when Redux maps global state to Accessible component properties in mapStateToProps. Primarily we build an "items" and a "parents" structures that are used when VirtualizedTree component methods are called (such as getParent or getChildren for an item).

What you would need to do is something like this:

• around https://searchfox.org/mozilla-central/source/devtools/client/accessibility/components/Accessible.js#438 you would need to check for ...if (name === "name") {...}

• then once you know you are processing a name you need to set the contents and children value for the name item. Contents would remain as is (e.g. the value of the name property).

• However children will be created using a function that you would need to define. It would need to take, probably, one argument which is the DOMNode object that is part of the props argument in makeItemsForDetails (https://searchfox.org/mozilla-central/source/devtools/client/accessibility/components/Accessible.js#431).

• In that new function you would create a children array that would use rules defined in https://searchfox.org/mozilla-central/source/accessible/tests/browser/e10s/browser_caching_name.js#29-55 (you could probably copy whatever you need to devtools/client/accessibility/constants.js and import it into Accessible.js)

What do you think? Feel free to ask more questions, this is not a trivial feature!

Thanks :)

Sounds good Yura, thanks for all your help

Hey Yura, I think I've got most of it working, just need a bit of help with the function that generates the list of children.

const generateNameCalculationAttributes = (DOMNode) => { ... };

I'm not quite sure what comes with the DOMNode object, does it contain the html element type? And if it doesn't what properties does it have that I can use to get the right list from the rules constant?

Sorry, don't think I flagged my last comment

(In reply to Bisola Omisore (Sola) from comment #9)

Hey Yura, I think I've got most of it working, just need a bit of help with the function that generates the list of children.

const generateNameCalculationAttributes = (DOMNode) => { ... };

I'm not quite sure what comes with the DOMNode object, does it contain the html element type? And if it doesn't what properties does it have that I can use to get the right list from the rules constant?

Sorry I missed your question, yes I believe it will have a lot of what you need. It's going to be a node front object described here:

https://searchfox.org/mozilla-central/source/devtools/shared/fronts/node.js#109

which is a front end for this node actor:

https://searchfox.org/mozilla-central/source/devtools/server/actors/inspector/node.js#46

You might find these methods helpful: https://searchfox.org/mozilla-central/source/devtools/shared/fronts/node.js#324,328,338 which is what you probably need to get the relevant attribute information.

You can also debugging the front end for the accessibility inspector using Browser Toolbox (see https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox). It is helpful to debug and inspect objects when you develop. You can either add breakpoints as you go or just pring debugger statement in code and then the toolbox will automatically break where you need.

Hey Yura!

It's been a while :). Thanks for the browser toolbox suggestion, it's a bit trippy to use at first but I was able to get a look inside the DOMNode using debugger.

I seem to be able to get the element type in two ways directly from the DOMNode, if the element is a button for example I can use:

A. DOMNode._form.displayName = 'button'
B. DOMNode._form.nodeName = 'BUTTON'

Is there a preference to which method I use?

...

After that I ran generateNameCalculationAttributes on a specific element (links, which are 'a') to see if it would work, but it crashed the accessibility window of devtools whenever I clicked on any occurrence of that specific element. The function looks like this:

const generateNameCalculationAttributes = (DOMNode) => {
  if (DOMNode._form_displayName === "a") {
    return NAME_CALUCLATION_RULES.HTMLLink;    // NAME_CALCULATION_RULES is a reference of the rules I copied in to constants.js
  }

  return [];
}

Thoughts?

(In reply to Bisola Omisore (Sola) from comment #12)

Hi Bisola,

Hey Yura!

It's been a while :)...

No worries at all.

I seem to be able to get the element type in two ways directly from the DOMNode, if the element is a button for example I can use:

A. DOMNode._form.displayName = 'button'
B. DOMNode._form.nodeName = 'BUTTON'

Is there a preference to which method I use?

I think we just need the node name, as display name might also include a prefix, which we are not interested in (as far as I can tell). In fact you can use this getter: https://searchfox.org/mozilla-central/source/devtools/shared/fronts/node.js#236 so you can just call your domNode.nodeName whenever you need it.

...

After that I ran generateNameCalculationAttributes on a specific element (links, which are 'a') to see if it would work, but it crashed the accessibility window of devtools whenever I clicked on any occurrence of that specific element. The function looks like this:

const generateNameCalculationAttributes = (DOMNode) => {
  if (DOMNode._form_displayName === "a") {
    return NAME_CALUCLATION_RULES.HTMLLink;    // NAME_CALCULATION_RULES is a reference of the rules I copied in to constants.js
  }

  return [];
}

Thoughts?

It's hard to say where exactly something failed, I might recommend checking the console in browser toolbox for any potential errors. That might be helpful. Also, if it helps, and I think it might, please feel free to post your review request (on phabricator) with whatever work in progress you have. This way I can also try applying your changes locally and maybe figuring out what was broken faster. This way we also both can track all the work that you are doing :)

Is there a way to clear the need info request without responding?

The bug assignee didn't login in Bugzilla in the last 7 months.
:Jamie, could you have a look please?
For more information, please visit auto_nag documentation.