Accessibility Schema

[dgovil]

Description of Proposal

As USD enters more widespread use, with a range of interactive experiences for spatial computing and the web, it becomes necessary to make sure we do not exclude anyone. It is important for 3D content to be as accessible as other media types for people with a range of needs that may require virtual assistive services.

To facilitate this, we propose the addition of accessibility metadata, using industry standard nomenclature.

def Mesh "Cube" (
    prepend apiSchemas = ["AccessibilityAPI"]
) {
    string accessibility:label = "Luxo, Jr"
    string accessibility:extendedDescription = "The lamp has round base with two sections above it that may be adjusted. It has a conical head with a lightbulb inside. It likes to chase inflatable balls"
    token accessibility:important = "standard"
}

---

Link to Rendered Proposal

---

This proposal has significant overlap with the Semantic Captions Proposal . We are discussing how to best proceed, and whether it is valuable to have both or merge the two etc...

Please leave your comments on either PR, whichever suits your note best.

Contributing

• I agree to and accept the Supplemental Terms.

[cookiecrook]

Looks good overall to me... Great start for object and container labeling.

One item I raised verbally before as a future consideration is that sometimes a relevant time sequence needs an "announcement" for assistive technology, too... Either tied to a transition (for example, between slide builds where the change is more important than either end state) or a time code of the overall timelines, similar to closed captions or audio descriptions.

[dennis-lynch-nv]

SemanticsLabelsAPI is also a valid accessibility information source, but the target goals are too different. Labels are geared towards data management systems versus human interaction.

I agree. And I'd like to re-use an argument I made with Semantics: Accessibility is important enough to be quickly and easily discoverable through the HasAPI method. Accessibility focused applications would be able to quickly identify which prims do or do not have accessibility information, especially with the proposed priority purpose (ex: a button the user can interact with is high importance, but its color or material is low importance).

If we were to "shoehorn" this in via Semantics, Accessibility applications would need to parse-through all the (potentially many) semantic instances to find ones related to accessibility, and/or the community would need to agree-upon specific Semantics instance names that are accessibility-related so that they could be quickly discovered.

The majority of the overlap I see with Semantic Captions is in the timeSamples examples, though that could just be because of the examples given.

Something like

string accessibility:extendedDescription.timeSamples = {
        50: "The sign says Do Not Walk",
        100: "The sign says Walk",
    }

seems more like "accessibility information" to me, though that could be splitting-hairs.

I think Accessibility information is important enough that I would also be wary of using it to dump Semantic Caption-like information, that could be overly-descriptive prompt input and not important information for the user to quickly access

[nvmkuruc]

@dgovil It seems like purposes could be represented as instances of multi apply schemas. I'm curious if you see any drawbacks to that.

[dgovil]

Would that be like what you do here?

apiSchemas = ["SemanticsCaptionsAPI:summary",
                  "SemanticsCaptionsAPI:skills"]

In that case, how would the default unprefixed purpose be declared? Would it just be SemanticsCaptionsAPI without the suffix as well?

[nvmkuruc]

Not being able to have instance-less multi apply schemas is something we have run into before. Our best recommendation under the current system would be to have a canonical instance-- like default. ie-- SemanticsCaptionsAPI:default.

@crevilla might have some thoughts here about the complexities of allowing instance-less multi-apply schemas. The risk I see is a greater potential for namespace collisions.

[crevilla]

I hadn't thought about it before, but I don't have a strong argument against allowing instance-less multi-apply schemas. An "instance-less" instance of a multi apply schema wouldn't be much different than a single apply schema and isn't really much different in regards to namespace collisions than single apply schemas.

We already validate against using property base names as instance names for multi-apply schema (during calls to Apply only, not in general). E.g. "includes" is not a valid instance name for applying CollectionAPI since all applied CollectionAPI instances have a collection::includes property. I don't see an immediately obvious issue that an empty instance would bring that we aren't already accounting for.

All that said, I'm not sure if an empty instance name is strictly better than a canonical "default" instance.

[nvmkuruc]

Thanks @crevilla! This is great info.

I think I would say that allowing empty instance names would be helpful when--
a) converting a single apply schema to a multiapply schema but still supporting legacy content.
b) making it clear to both OpenUSD and users what the canonical instance is. Otherwise, it's just a convention.

But a) might rare and b) could be satisfied by adding some metadata to your schema about preferred instance names.

[dgovil]

Just picking this comment thread up again,

Perhaps it makes sense to just have the default purpose be explicitly accessibility:label:default rather than be implicit? Then there's no logic that needs to be thought about, and its fairly straightforward to do a 1:1 mapping at the expense of a little verbosity?