Meeting minutes
Branching best practices
pkra: somebody created this draft item. Not sure who and why.
spectranaut_: maybe we created this during a meeting? E.g. about not forking (for WG members)
pkra: ok. Then let's delete. Hopefully we'll remember.
[aria.js] generate roleInfo after respec runs (aria #2769)
pkra: just wanted to touch base.
… I felt this was cleaner, even if it duplicates some things.
spectranaut_: will it add extra work to change things on both end?
pkra: right. Potentially, yes. But I'd hope it would be 2 changes in aria.js vs 1 in each.
… long term, I'd hope to remove as much as possible from aria.js
spectranaut_: right. It is already easier to reason about.
Rahim_: would it be possible to generated from the IDL block?
… generate the characteristics tables
pkra: sure. Feels like it should be the other way around though since the IDL block is informative.
<spectranaut_> w3c/
IDL PR 2484
spectranaut_: preview is not working. Maybe because of a fork.
pkra: I'm always in favor of avoiding manual duplication. But perhaps let's get it merged first, since it's been sitting for so long.
Rahim_: right. Thinking about it because there are new values on the IDL side.
spectranaut_: should we review this?
Rahim_: not right now. I need to update it. And we should touch base with the salesforce people.
spectranaut_: right. we also need to work out what to return for the getAccessibilityProperties.
… now that I work on it, I have a better understanding of the subtleties.
Add support for role-namerequired-caveat (aria #2781)
pkra: link is w3c/
… this issue is w3c/
… but really w3c/
… I'm not worried about the roleInfo implementation but the problem of conditionals in general.
… are we creating an uncontrolled set of conditions that implementors will struggle to follow?
scotto: I initiated some work to remove some of these. E.g. required names when HTML's equivalent does not.
… we have requirements that stem from accessibility considerations that fit better elsewhere.
… e.g. the listbox case.
… we did some of that in html-aria, too.
… the bigger question is whether we work against other specs.
spectranaut_: I feel that if the exemptions are programmatically detectable, then at least we enable checkers to do it.
pkra: I'm more worried about creating a kind of spaghetti code situation where more and more conditionals are combined to make a tangled mess.
scott: maybe more complex conditionals could be resolved by creating new roles which would integrate those.
pkra: that's a great point. At least one way out.
spectranaut_: I'm not sure how helpful it would be to have more roles that do essentially the same.
scott: e.g. sectionheader/footer. These are basically group's. But it helps with authoring.
… it would simplify mappings but no difficulty in implementations.
spectranaut_: you could almost say that the conditionals change the role under the hood.
scott: right. sort of like a base role.
… it helps with authoring requirements.
… I'm not sure if it's much easier for authors. They'll have to learn it either way.
pkra: aside, I had to think about the DPUB aria roles, both as pro and con.
scott: this was just the first idea I had. I think we should think more about it to make sure we have more options.
… I don't think we're having problems with the current proposals but I agree that it would be good for the WG to think about options in the longterm.
pkra: thanks everyone for indulging this topic.