Any other views on this, esp. now that definition of address has been updated, and has a default role of group?

I'd suggest that address not be mapped as a landmark, and that all APIs just use WAI-ARIA mapping for the group role, unless UIA and AX want their own localised strings, e.g. "address".

@stevefaulkner, @surkov, @joanmarie, @cookiecrook, @boggydigital?

@jasonkiss my thinking is that due to historic misuse and recent change in definition (to better match usage and developer understanding) it should map to group, and be exposed as object attribute xml-roles: address in Ia2

sounds good with me to go with group role and xml-roles:address object attribute. I'm not sure I caught how we want to proceed with Apple landmark mapping, will it be changed? Otherwise I'd say it makes IA2/ATK out of sync with AX.

Agreed. So, putting it all together, we're proposing something like the following, right?

• WAI-ARIA: Group role
• MSAA + IAccessible2
  Roles: ROLE_SYSTEM_GROUPING
  Object attributes: xml-roles:address
• UIA
  Control Type: Group
  Localized Control Type: "address"
• ATK
  Role: ATK_ROLE_PANEL
  Object attributes: xml-roles:address
• AX
  AXRole: AXGroup
  AXSubrole: (nil)
  AXRoleDescription: "address"

@boggydigital, @joanmarie, @cookiecrook care to confirm/comment?

(pardon my vacation delay)

Don't have strong objection and strongly support address not being a landmark. At least for UIA it sounds like more suitable control type would be Text, not Group. Unless this is about some structural address that contains separate elements, I would treat address as just a piece of text that has some semantic value.

Thanks @cookiecrook for the thumbs up.

@boggydigital, address can contain separate elements, including separate elements each with specific RDF metadata. Given that it also maps by default to the group role, it would at least be consistent were address to map similarly across all the APIs and inherit from that WAI-ARIA mapping.

No objection from me - I can see how semantically Group does make sense here

I wish I had paid attention to this thread sooner.

I HATE, HATE, HATE the overuse of group and the effect it has on screen reader experiences. 99% of the time it just adds clutter. It rarely adds value. It can even add confusion.

This is a perfect example. I think the default mapping should be like a div, just a text node.

Please let designers/authors decide if something needs to be done to make addresses standout for screen reader users. For instance, since group is allowed by html, the author can decide whether to add role group with aria-roledescription. Or, the author can decide to do nothing.

Automatically adding excess verbosity or interaction is not helpful to users.

If we think address is a semantically valuable tag, then we should consider giving it a role in a future version of ARIA. But, please, group is not a helpful stopgap.

Since in each API we're specifying (as per my comment above) a relatively simple mapping to a generic grouping container (just as div and a number of elements already use), but with a localized string or object attribute to indicate the grouping is an "address", we probably don't want/need to specify group as the address element's corresponding ARIA role. See the updated mappings for address.

Closing, but if you still have concerns, @mcking65, feel free to reopen for discussion.

I wish I had paid attention to this thread sooner.

I wish I had seen it.

I HATE, HATE, HATE the overuse of group and the effect it has on screen reader experiences. 99% of the time it just adds clutter. It rarely adds value. It can even add confusion.

Yeah, the current mapping for my platform would cause Orca to say "panel" for each address. Along with "leaving panel" upon exit, for those users who have enabled extra context messages. Yuck.

This is a perfect example. I think the default mapping should be like a div, just a text node.

I agree. I'm going to open a new issue fix the mappings at least for my platform.

On a happy note, Gecko already treats address like a div.