Matthew: still looking at this - in terms of the major changes - certain things are fantastic and have been needed for some time - others are natural extension of what they were doing before. They know what they're doing. Worried that some features might be used in replacement of other features they should use... But that's only my personal concern. Those aren't architectural concerns. Some of the things that have been added - e.g. semantics for change suggestions - when supported that will be really helpful. I haven't been all the way through list of substantive changes but so far i haven't seen anything concerning. Will be done by next week...

Yves: why is ARIA description just a string? You may want to have translations?

Matthew: there are good reasons for it - and the precedent has been set a long time ago -- there used to be "ARIA described by" pointing to an ID.. The hope is people use existing text in the DOM... For providing an accessible name - it usually comes from the content of the element - or a label - but ARIA gives you a way of overriding. I understand why they've allowed this - but needs to be stronger in the documentation - don't use the string attribute if you can avoid it. If you've used "described by" and you also have description the described-by takes precedence. I've been told by accessibility experts that this can make translations harder... however precedent has been set... They've also now got "ARIA details" - it seems this more heavy descirption - but this is an ID Ref - not a string. It's like a description but expected to be more detailed... You've got a name (short), described by (longer), details (a bit more about it). Pretty certain that they've called it that on purpose...

Yves: it seems inconsistent...

Matthew: Agreed... however overall it looks good. It may be worth asking some questions. This isn't a horizontal review request so I think it's worth taking a little longer and noting those things down...

Yves: should comment be comments?

Matthew: it's a tree so comment is appropriate. Also braille label and braille description - also string values - that makes more sense.

Matthew: APA are looking at this in a slightly different way. We're looking for architectural stuff in this context. Good discussion on this last week, including helpful comments from Yves. I looked into the major features and also the substantive changes since 1.2. My comment. tl;dr everything is fine in my opinion. A couple of things we talked about last time, the naming of aria details, it accepts a list of id refs, but it's not called aria detailed by like the other labelled by and described by. The reason is there's no way that information is designed to fit into a flat string. It's supposed to be structured. Inconsistent but it's actually sensible, it sets the expectation that there isn't going to be a flat string version of this. Plus it was added in aria 1.1, the only thing in this version 1.3 is to change it to allow for multiple id refs, like the other two. It's been out there for some time.

Dan: is there any point in suggesting they should have both names? Concerned about developer complexity.. it's one thing to say this is how it was in 1.1.. but if someone is coming at it new.. they might see a pattern and then it doesn't work. Naive question.

Matthew: It's a good question, naming consistency is important. I think, if they were to add a synonym - they've done this for one of the roles, presentation, which actually meant there are no semantics on this element - and people didn't understand it, so they added 'none', it makes more sense that it doesn't have a role. There is a precedent for doing that. The challenge with this one is if you added detailedBy as a synonym you've also got inconsistency with label and labelledBy, you'd think it doesn't take aria refs but it does... I don't think we can make this better by changing the name. There are lots of attirbutes that accept id refs in all sorts of specs, and there isn't by on the end of them. It's not 100% optimal but I can see arguments on both sides why this was named what it was. I tried to look into it and find their discussion on this and the gh history doesn't go that far back. I can investigate...

Dan: doesn't sound like it's worth it

Matthew: agree. I don't think it can be improved by making the obvious change. I think it would end up being more confusing. Also label, labelledBy, description, describedBy map to the two most important things about an element. Name and description being consistent with each other is more important than other things are.

Matthew: Yves asked about translation wrt to the properties like description, role description and label, and the fact the attirbute value is a user facing string.

Yves: my main concern was i18n's reaction to that kind of thing - just a string with no indication of language

Matthew: good question. I didn't find any discussion around concerns raised by i18n. There have been these flat string attributes in for a very long time, so plenty of time for i18n to object if they were going to. Did want to spend more time looking at how translation works. It's not my area of expertise. I did find a section in the spec about translatable attributes and it does talk about how that works, which attributes are expected to be localisable, and it gives a list. Minor bug - aria-description which is new isn't included in that list, which is clearly a bug, it's obviously supposed to be. I'll file an issue on the spec.

Matthew: for APA specifically - consider recommending adding slightly stronger wording against the use of things like aria label, description, role description - I've seen a lot of misuse of them. But it's valid that it's there, people need to use it right. There's pretty good guidence on how to do that. Maybe APA should add a stronger note to discourage that. We see a lot of overuse of aria label. There is a really strong note against over use of braille label and braille description.

Dan: suggest we close as satisfied with a brief closing comment. Thanks

<blockquote>

Thanks for your review request. We have no architectural concerns. There are a lot of really helpful new features, changes, and clarifications in this version, which will be of great help to users; great work!

</blockquote>