Hi Rich,
I understand the reason for the use of the landmark role for
role="form". However, I disagree with the HTML form element being mapped
to the landmark role because semantics are lost. The fact that something
is a form has more semantic value than just being a landmark. Still, if
the
Hey Rich.
Understood regarding non-normative requirements on ATs. But note that my
statement didn't say who would hold those expectations. If authors
expect it and/or users expect it, and other screen readers meet that
expectation, then Orca should also meet it. Moreover, if NVDA provides
that
Well, If you had an error message I can certainly see the need for the user to, after they have gone to the error message, go back to the associated control to fix the error. ... aria-details reverse relationship, I don't believe, is as critical. We do not, however, put normative requirements on
These were the original relation names for error message and details
IA2_RELATION_DETAILS
IA2_RELATION_ERROR_MESSAGE
I also have these relationships for ATK/ATSPI:
RELATION_DETAILS
RELATION_ERROR_MESSAGE
They are listed in this branch I am working on:
Jamie,
The point is we want ALL the landmarks to be treated the same way for ATVs. So,
first we determine that it is a landmark. Then we go to xml-roles to determine
the type of landmark.
Otherwise, we need a special case for a form. That is what we are trying to
avoid. For these reasons
ok.
So, Alex, please provide me the name of the two IA2 relationships fore details and error message? I will work with joseph and amelia to look at concatenation of error messages in the description.
Also, Joanie expressed a desire to have reverse relationships for details and error message. I
Hey Rich.
On matters where I have no strong opinion, but Jamie does, I defer to
Jamie. Mapping of aria-details and aria-errormessage for my platform
falls into this category, at least currently. Let's suck it and see.
--joanie
On 08/24/2016 10:39 AM, Richard Schwerdtfeger wrote:
> Alright. I am
