Reuse visual strings for description in MOTHA.

[pixelzoom]

Related to #67 ...

For description strings, we are currently using the approach that was used in MOTHA. All description strings (accessibleNames and helpText) are under ModelsOfTheHydrogenAtom.a11y and no visual strings are reused.

PhET is starting to build out support for default accessibleName, where the visual string is discovered and used for accessibleName. Do we want to take advantage of this in MOTHA, or use MOTHA to prioritize building out this feature?

[pixelzoom]

11/7/24 design meeting: @DianaTavares @arouinfar @kathy-phet @terracoda @LindaStegemann @ariel-phet @KatieWoe @pixelzoom

Consensus is yes. @jessegreenberg and @pixelzoom will work on this.

[pixelzoom]

Here's an inventory of UI components used in MOTHA where accessibleName is the same as the visual string:

• ABSwitch (from labelA and labelB constructor args)
• AccordionBox (from options.titleNode)
• AquaRadioButton (from labelNode constructor args)
• Checkbox (from content constructor arg)
• ComboBoxItem
• Dialog (from options.title)
• RectangularRadioButton (from options.content)

@jessegreenberg does this help with identifying which common-code UI components to prioritize?

[jessegreenberg]

Yep, that is very helpful, thanks. Ill also make note of that in phetsims/sun#911.

[pixelzoom]

Great. Keep me posted as the "discovery pattern" (findStringProperty) is added to UI components. Then I'll remove strings from MOTHA that are discoverable and therefore unnecessary.

[jessegreenberg]

Ok, PDOMUtils.findStringProperty is implemented an all of the above components. @pixelzoom you should be able to remove the accessibleNames with TODOs pointing to this issue.

[pixelzoom]

I've removed the strings that are now unnecessary (because they are discoverable). We are down to 12 strings for accessibleName. We also have 10 strings for helpText.

I don't see any other opportunities for using defaults here, so I'll close this issue.