Support multiple settings being defined in *-commands.csv

[howard-e]

Preview Tests

Address #1002.

Note: Created #1126 to test the changes on tests/alert/data/jaws-commands.csv (these are not meant to replicate real world defined settings or scenarios):

• Alert review page showing that the JAWS command has an additional speechRateIncrease and commentAnnouncementOn setting. Also added a new Enter + virtualCursor + commentAnnouncementOn command
• Alert test page for JAWS commands also accounting for the additional settings

Note2: This work should NOT be merged until a supporting PR is included on w3c/aria-at-app as the resulting test format output is being changed to have an additionalSettings property.

[howard-e]

cc @mcking65

[jugglinmike]

This definition of settings isn't really appropriate in the presence of additionalSettings. Will this change also be reflected in the test format definition? What would be the ramifications of renaming this property to primarySetting?

[howard-e]

This definition of settings isn't really appropriate in the presence of additionalSettings ... renaming this property to primarySetting?

I agree! I figured as much when sharing the initial gist on what's different here. I proposed mainSetting then and have since used primarySetting here as well which feels more appropriate. Otherwise, it certainly presents a bit of confusion without this context.

Will this change also be reflected in the test format definition?

I don't think it necessary. Seems to be something to consider as an implementation detail.

What would be the ramifications ...

A widespread refactor across the references in this repository, aria-at-app (as well as some migration or backward compatibility work) and also in aria-at-automation-harness and related resources I assume. That will certainly need a bit of coordination that I'm uneasy trying to get that done now. Do you feel strongly otherwise?

[jugglinmike]

I agree that it's an implementation detail for the Community Group at large. That said, the amount of inter-project coordination needed to support change makes it feel like a public-facing design.

This change creates a gap between what the CG calls "settings" and what code maintainers call "settings", and to me, that's a problem which is distinct from the internally inconsistent names.

I dropped in from w3c/aria-at-automation-harness#73 to verify that my understanding of the situation was accurate. I trust your judgement when it comes to coordinating changes; I'd only advocate for prioritizing that refactoring sooner rather than later!