Add support for Accessibility Export

[dgovil]

We recently added support for Accessibility metadata and are trying to enable the creation of more accessible USD files out of Maya.

This first implementation supports adding data on the default prim and corresponds with a matching PR we will be making to Blender. This adds two new fields to the Advanced group.

Our goal here is to enable third party developers and internal pipelines to store the data in their USD files so they can surface it to accessibility runtimes.

Since Accessibility was only added in USD 25.5, I currently implemented this by ad-hoc writing the attributes. I realize that Maya 2026.2 has 25.5 mode, but many of our third party developers aren't yet able to upgrade to Maya 2026 or run in the OpenUSD 25.5 mode. Once Maya has 25.5 ubiquitously available, I can replace this with the actual AccessibilityAPI calls, but in the meantime the test validates the result against the USD 25.5 when run in that mode in your CI.

[scottrenaud]

Hey Dhruv, this is awesome! Might I request some tweaks to the UI if possible?

In the Export Options

1. Let's place the "Accessibility" section above the "Axis & Unit Conversion" section. (alphabetical order under Advanced can help with scanning)

In the Attribute Editor

2. Would it be possible to place any "AccessibilityAPI" sections after "Asset Info" to keep related details together?

3. I'm told there's a "prettifyname" function where we can change the attribute labels to make them easier to read, would be nice if we could make the following changes:

• Accessibility Default Label -> Label
• Accessibility Default Description -> Description
• Accessibility Default Priority -> Priority

See this image where they don't look so good:

Let me know if you have any questions, thanks!
Scott

[dgovil]

@scottrenaud
Oh that's interesting, I didn't actually add the attribute editor stuff as part of this PR and didn't think to check if it showed up.

@seando-adsk I assume that shows up because of the automatic attribute editor creation that happens? I'll take a look into moving it into a more intentional spot as requested.

Either way, thank you both for the feedback. I'll take a pass at these next week.

[dgovil]

Oh also just a note, the reason the "Default" appears in the attribute editor, is because it's a multiple apply schema, where each instance can have a name and "default" is the name of that instance. But you can have arbitrary other names too for different purposes.

I suspect, based on the current automatic treatment that the attribute editor doesn't special case for multiple apply api schemas yet.

@scottrenaud how would you feel about a slight modification to your proposal, where instead of having the label, description etc right under the AccessiblityAPI group, we introduce a group in between for the name?

So in your suggestion it would be "AccessibilityAPI > Label" as the view hierarchy, but I think it might be more flexible to be "AccessibilityAPI > Name > Label" where name is the name of the specific instance.

The AccessibilityAPI isn't the only multiple apply API schema but this could at least set precedent for the others.

[scottrenaud]

Hey Dhruv,

That could work, I think the only downside is that if there's only 1 schema applied, then we have 2 groupings.

At the moment we treat each USD Collection (also a multiple apply schema) as a separate section/rollout, so I was thinking it'd be ok to do the same with Accessibility, ex: name1 Accessibility, name2 Accessibility,...

I'm ok either way and we can always iterate.

Thanks!,
Scott

[dgovil]

Yeah totally fair point. Okay I'll try that out, and see how it feels.

I'll ping the thread next week when I have updates ready.

Thanks again for the input.

[dgovil]

@seando-adsk I've discovered a bug in the ae_template.py that I'd like to run by you.
In orderSections, if a schema is ordered after extraAttributes and metadata, any attributes that are part of it get swallowed into Extra Attributes.

If you take a look at desiredLastSchemas, I've added .*AccessibilityAPI after assetInfo as requested, but if I do that, it gets swallowed into Extra Attributes. If I move Extra Attributes in that same list to after my entry, it gets its own section.

I tried this with some other schemas and it seems consistent.

I'll see if I can figure out what's causing it and fix it in this PR, but I wanted to flag that to you.

[dgovil]

Ah looks to be an easy fix. createCustomExtraAttrs is written as extraAttrs = [attr for attr in self.attrS.attributeNames if attr not in self.addedAttrs and attr not in self.suppressedAttrs] but it should also check if any of the attrs are in the schemaAttributes list first.

I'll fix that up

[dgovil]

@scottrenaud and @seando-adsk I think I've hit all the notes.

To hit the notes, I did have to be a little more extensive in my changes. I don't think anything I did should be objectionable, but I just wanted to call attention to it:

1. I added code to generically handle unknown API schemas if they follow the common pattern of being called <name>API:<instance> (where instance is optional) and their attributes are prefixed with <name>:<instance>:. This catches the Accessibility schema and a few other schemas I've seen in the wild. Of course it's not all encompassing, but it should work for more cases. This is needed for Maya versions that are lower than 25.5 since they don't know what the Accessibility schema is.
2. I fixed the Extra Attributes section because it would swallow any attributes that hadn't been added yet, which prevented sections from coming after it.
3. I added the ability for the section creator to also use a wildcard match , like the section ordering does.
4. I added the ability to provide custom labels to the controls that are created

Here's the export UI

and the attribute editor

[seando-adsk]

@pierrebai-adsk Can you please review the code? Once you approve just let me know (before running a preflight). We want to run the preflight with the zips so that QA can test before we merge. Thanks, Sean

[pierrebai-adsk]

Extremely minor nit-pick, would work without that requested change really. So it could be merge if it is urgent or anything.

[pierrebai-adsk]

Good job!

[seando-adsk]

Hi @dgovil I ran the preflight, and unfortunately there are two problems:

Compiler error - I think just missing the #include
.../2026-usd2505-interactive-linux/ecg-maya-usd/maya-usd/lib/mayaUsd/fileio/jobs/writeJob.cpp:73:1: error: expected unqualified-id before ‘<’ token
73 | <pxr/usd/usdUI/accessibilityAPI.h>
| ^

2024 Linux: Test Failure:

======================================================================
FAIL: testAECustomMaterialControl (__main__.AttributeEditorTemplateTestCase)
Simple test for the MaterialCustomControl in AE template.
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 325, in testAECustomMaterialControl
    materialFormLayout = self.findExpandedFrameLayout(startLayout, 'Material', fullPrimPath)
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 97, in findExpandedFrameLayout
    self.assertIsNotNone(frameLayout, 'Could not find "%s" frameLayout' % labelToFind)
AssertionError: unexpectedly None : Could not find "Material" frameLayout

======================================================================
FAIL: testAEForDefWithSchema (__main__.AttributeEditorTemplateTestCase)
Test that the expected sections are created for def with added schema.
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 580, in testAEForDefWithSchema
    self.assertListEqual(
AssertionError: Lists differ: [] != ['Light ', 'Light Link Collection ', 'Shadow Link Collection ']

Second list contains 3 additional elements.
First extra element 0:
'Light '

- []
+ ['Light ', 'Light Link Collection ', 'Shadow Link Collection ']

======================================================================
FAIL: testAEForLight (__main__.AttributeEditorTemplateTestCase)
Test that the expected sections are created for lights.
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 531, in testAEForLight
    self.assertListEqual(
AssertionError: Lists differ: [] != ['Light ', 'Cylinder Light', 'Light Link C[34 chars]on ']

Second list contains 4 additional elements.
First extra element 0:
'Light '

- []
+ ['Light ',
+  'Cylinder Light',
+  'Light Link Collection ',
+  'Shadow Link Collection ']

[dgovil]

Ah my bad. I accidentally removed the include keyword in my last commit.
Hit one too many undos.
Added it back.

I'll take a look at those attribute editor issues next. Not sure what would have caused them.

[dgovil]

Hmm @seando-adsk , I'm not sure why the Maya 2024 tests fail for the material tests, and I don't have 2024 on hand to test with.

I fixed the collections issue though.

I'm running in 2026.2 locally, and my tests pass + I verified interactively

testAECustomMaterialControl

[seando-adsk]

@dgovil Ran preflight again and got another build error in Maya 2026:

...\2027-windows-release\ecg-maya-usd\maya-usd\lib\mayaUsd\fileio\jobs\writeJob.cpp(1405): error C2065: 'defaultAPI': undeclared identifier
...\2027-windows-release\ecg-maya-usd\maya-usd\lib\mayaUsd\fileio\jobs\writeJob.cpp(1408): error C2065: 'defaultAPI': undeclared identifier

The 2024 build still failed the AE test:

======================================================================
FAIL: testAECustomMaterialControl (__main__.AttributeEditorTemplateTestCase)
Simple test for the MaterialCustomControl in AE template.
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 325, in testAECustomMaterialControl
    materialFormLayout = self.findExpandedFrameLayout(startLayout, 'Material', fullPrimPath)
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 97, in findExpandedFrameLayout
    self.assertIsNotNone(frameLayout, 'Could not find "%s" frameLayout' % labelToFind)
AssertionError: unexpectedly None : Could not find "Material" frameLayout

======================================================================
FAIL: testAEForDefWithSchema (__main__.AttributeEditorTemplateTestCase)
Test that the expected sections are created for def with added schema.
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../2024-interactive-linux/ecg-maya-usd/maya-usd/test/lib/testAttributeEditorTemplate.py", line 580, in testAEForDefWithSchema
    self.assertListEqual(
AssertionError: Lists differ: [] != ['Light ', 'Light Link Collection ', 'Shadow Link Collection ']

Second list contains 3 additional elements.
First extra element 0:
'Light '

- []
+ ['Light ', 'Light Link Collection ', 'Shadow Link Collection ']

If you need help with the 2024 test let me know and I can have someone try it internally.

Sean

[dgovil]

@seando-adsk Thanks for running the clang-formatter. I fixed the build issue as well.
If you do have someone with Maya 2024, that would be amazing. I'll try and fish out our old setups as well, but it might take a bit.

It is odd that it only fails on 2024, which makes me think it might be a Python version difference? But I ran the code through Jetbrains compatibility checker and it didn't flag any issues for Python 3.10 (which is what I recall 2024 using)

[pierrebai-adsk]

@dgovil I pushed a commit to your branch in your repo that fixes the problem on Maya 2024. Is was due to using an API not available on USD 0.22.

[dgovil]

Ah thank you very much for catching and fixing that, @pierrebai-adsk !