Revisit query parameters and package.json entries related to supported and designed features.

[pixelzoom]

Related to phetsims/models-of-the-hydrogen-atom#67 and https://github.com/phetsims/scenery-phet/issues/876 ...

In phetsims/joist#985, we discussed having a tiered approach to description features, with "levels of description". If that's the case, PhET may want to revisit the approach to enabling description features.

In package.json, there is currently one entry under "simFeatures" that turns all description features on/off. From initialize-globals.js:

    /**
     *
     * Enables interactive description in the simulation. Use this option to render the Parallel DOM for keyboard
     * navigation and screen-reader-based auditory descriptions. Can be permanently enabled if
     * `supportsInteractiveDescription: true` is added under the `phet.simFeatures` entry of package.json. Query parameter
     * value will always override package.json entry.
     */
    supportsInteractiveDescription: {
      type: 'boolean',
      defaultValue: !!packageSimFeatures.supportsInteractiveDescription
    },

With only a single entry, it's not possible to turn off work that is not completed or not ready for production. For example, MOTHA has a complete alternative input implementation, but an incomplete implementation for accessible names and help text. If PhET wishes to publish MOTHA with alternaive input, but turn off description, there is no way to do that.

PhET might want to have package.json entries (and associated query parameters) that correspond to the description tiers. For example, "supportsAlternativeInput", "supportsStateDescriptions", "supportsResponsiveDescriptions" (or whatever matches the eventual tiers).

[marlitas]

Meeting 11/19

• supportsInteractiveDescription turns on the PDOM which in turn allows anyone to access alt-input, description, etc. whether it has been designed or not.
• We believe that adding entries that communicate the different tiers would be useful for website and management metadata, but may be confusing to developers if they believe other things are actually getting turned on when it's more like a flag to indicate it has been thought of and designed.
• These recommended names match query parameters and that is intentional. Any changes should update query parameters as well.
• We may want to add a supportsUISound as well in this case.
• We should take this discussion to dev meeting to see how devs feel about this change in approach to simFeatures in package.json
• If we decide not to do this in package.json it would be nice to have this information in the code rather than relying on updating metadata manually on the website.