Support multiple settings being defined in *-commands.csv
#1125
Conversation
|
cc @mcking65 |
lib/data/parse-test-csv-row.js
Outdated
| ) { | ||
| const commandInfo = { | ||
| testId: command.testId, | ||
| command: command.command, | ||
| settings: command.settings || 'defaultMode', | ||
| settings: primarySetting, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
This definition of
settingsisn't really appropriate in the presence ofadditionalSettings... renaming this property toprimarySetting?
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?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
@jugglinmike @outofambit having come back to this now, I've walked back on this implementation approach of "additionalSettings". Rather, sticking to handling the space separated string of "settings" as it is. My introducing "additional" settings represents another sense of settings priority that doesn't necessarily reflect the intention of #1002 (comment).
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.
Fair point! I also started #1180 which I hope brings us to a "v1.5-esque" change where we can remove a lot of unneeded code, references which haven't been relevant for some time and further help standardize the language between the maintainers and the CG.
lib/data/parse-test-csv-row.js
Outdated
| // TODO: Account for a list of settings as described by https://github.com/w3c/aria-at/wiki/Test-Format-Definition-V2#settings | ||
| const settingsValue = command.settings || 'defaultMode'; | ||
| const [primarySetting, ...additionalSettings] = command.settings | ||
| ? command.settings.split(' ') |
There was a problem hiding this comment.
This structure with the primary setting as the first item in a space-separated collection feels a bit fragile. I'd rather have this as a distinct column. It feels like there is significance not surfaced by a quick read of the input. I assume that this is a design decision towards a better authoring experience so I support leaving as-is for now
There was a problem hiding this comment.
Relevant to my reply here, I agree with that point. I've reverted this approach
tests/resources/aria-at-test-run.mjs
Outdated
| screenTextRender = `${screenTextRender} and ${settingsText}`; | ||
| }); | ||
| } | ||
| screenTextRender = `${screenTextRender})`; |
There was a problem hiding this comment.
Could also possibly be combined with the similar code above?
There was a problem hiding this comment.
This has been changed slightly. Do you still feel the same here?
…settings rather than additionalSettings value
…ather than additionalSettings value
…re are multiple settings
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):speechRateIncreaseandcommentAnnouncementOnsetting. Also added a newEnter + virtualCursor + commentAnnouncementOncommand