v2 Test Format: Space-separated settings in AT_KEY-commands.csv

[stalgiag]

We have been working to merge the work in #997 and make adjustments to aria-at-app in preparation for the v2 test format landing. As we are doing that work, we have read in Howard's notes that one aspect of the v2 test format has not yet been accounted for in that PR, space-separated listing of setting names in AT_KEY-commands.csv.

The reasoning given for the absence of this feature is two-fold. One is that it would increase the complexity involved in building the review and test files. Second, there is a sense that the use-case this feature aims to support is already supported.

Howard provided two possibilities for how this use-case might be supported without adding the space-separated settings list in AT_KEY-commands.csv.

1. Test authors could write additional rows for each settings value using the same whole number in the presentationNumber. I believe Howard's thinking was that these additional rows would exist in AT_KEY-commands.csv. The proposed authoring might resemble this:

testId,command,assertionExceptions,presentationNumber
reqInfoAboutBreadcrumbLink,virtualCursor,,7
reqInfoAboutBreadcrumbLink,ins+tab,,7.0
reqInfoAboutBreadcrumbLink,ins+up,,7.1
reqInfoAboutBreadcrumbLink,pcCursor,,8
reqInfoAboutBreadcrumbLink,ins+tab,,8.0
reqInfoAboutBreadcrumbLink,ins+up,,8.1

2. Another proposal given by Howard was that "The assertionStatement (in assertions.csv) can still describe an additional ‘settings’ value being used without it existing in the settings column." I am less clear on what is meant by this proposal. It is possible that we could parse and remove a settings key from the assertionStatement and use this in combination with the AT to render the relevant settings instructions where applicable.

@mcking65 What are your thoughts on either of these approaches being used in lieu of the space-separated settings list in the AT_KEY-commands.csv files? I read the discussion in #974 to see if there is a reason for this column that both Howard and I are missing. I didn't see anything obvious but it is possible that we both missed something.

If we are mistaken and find that the space-separated settings list isn't adequately supported elsewhere, then this feature will be added in a follow-up to #997. The goal of this issue is to get the ball rolling on this discussion so that we are well-positioned to address feedback upon Howard's return.

related to #977

[mcking65]

we need it to work as specified in the V2 format specification. It can be a follow-on feature. The current use case of one setting is adequate for all of our current tests.

Settings are screen reader specific, so they can only go in the screen reader specific mapping file and must be included in the screen reader specific commands.

When multiple settings are required, they are required simultaneously, not at separate times or in separate executions of the same command. Essentially, the "collection of settings" is part of the command in the same way that a "collection of keyboard commands" makes up a "command sequence".

Example: Ddown Arrow with Virtual Cursor active and Comment Announcement on

This is not two separate commands or tests.