Re: [Accessibility-ia2] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[James Teh]

To clarify, I'm concerned about aria-errormessage here. For 
aria-details, we wouldn't be trying to report the information as one 
chunk. Instead, the user would perform a command to navigate to the 
details, at which point they would browse it like they browse any other 
content.



For aria-errormessage, the use case I'm concerned about is when the user 
focuses an aria-invalid element with aria-errormessage. In that case, we 
need to report the aria-errormessage content as one chunk. Because this 
is focus handling, we don't use the buffer for this. There may not even 
be a buffer in this case, since we don't need a buffer in, say, an ARIA 
role="application".



Jamie

On 8/09/2016 2:15 AM, Alexander Surkov wrote:
Shouldn't it be same speed as walking the virtual buffer? I assume 
aria-details may contain complex content, for examplePythagorean 
Theorem from [1], that may be not suitable for stringification in general.



[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details

On Tue, Sep 6, 2016 at 11:31 PM, James Teh > wrote:


That doesn't solve the need to walk the tree to gather the error
message, which is the real problem.


On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:

I think Dominic's suggestion on an interface tester with bit
flags works well.
Rich


Rich Schwerdtfeger

- Original message -
From: James Teh  
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
surkov.alexan...@gmail.com
,
ble...@freedomscientific.com
, jdi...@igalia.com

Cc: accessibility-...@lists.linux-foundation.org

Subject: Re: Agreement on concatenation of aria-describedby
and aria-errormessage relationships
Date: Tue, Sep 6, 2016 7:19 PM

Fair enough. Thanks for the clear reasoning.

My one remaining concern is performance, but we will clearly
need to find an alternative technical solution to this
problem. In short, not concatenating means that for every
focus event, we need to check for the invalid state plus an
errormessage relation and then, if one is found, walk the
tree for the target to gather the message. The latter in
particular could be unacceptably slow.

On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote:

The ARIA working group is against concatenating the
description and relationship strings. I will try to summarize:
Specifically, concatenation by browsers could:

 1. Defeat the purposes of aria-errormessage. The
aria-errormessage relationship is designed to ensure
assistive technology users are as aware of error
messages as other users and to enable them to
distinguish between error messages and field
descriptions. The constraints of ARIA 1.0, and every
other accessibility standard and API that preceded it,
have forced developers to blend error messages and field
descriptions. This blending has long inhibited both the
perception and understanding of error messages, which
are critical to effective operation of many user interfaces.
 2. increase cognitive load for users when errors are
present. Especially for screen reader users, we already
have severe challenges with excess verbosity that forces
the user to expend energy sorting out the most important
aspects of screen reader feedback. Concatenating
potentially very disparate content in this manner would
aggravate the verbosity problem.
 3. Reduce assistive technology flexibility. Part of the
power of ARIA is that it gives assistive technologies
the ability to present content in the manner best suited
for their target audiences. When browsers eliminate
semantically relevant distinctions, this type of
flexibility is diminished. If this concatenation were
performed, it would essentially eliminate the semantic
distinctions.  If an assistive technology developer
wanted to present the field description separate from
the error messages, the developer would be forced to
ignore the browser-computed description when error
messages are present and reconstruct the description
computation within the assistive technology.
 4. Lead either browsers or authors to devise their own
string-based tokenization capability. Because
aria-errormessage is a separate relationship, there will
be designers and 

Re: [Accessibility-ia2] Reverse relationships

[James Teh]

Agreed. Happy to have a reverse relation for errormessage, since we seem 
to have a use case. We don't seem to have a compelling use case for a 
reverse relation for details, so let's leave it out for now.



On 8/09/2016 5:25 AM, Richard Schwerdtfeger wrote:

Hi Alex,
Correct, aria-details requires no special role. However, the use case 
is for the digital publishing industry. They want to be able to take a 
piece of content and go to the alternative content that provides 
detailed information which could be alternative content as we 
discussed previously. The user may or may not wish to go back to the 
content the details is being provided for.
The need for a reverse relationship for the error message is more 
critical.
So, do we agree on a reverse relationship for error message and not 
details?



Rich Schwerdtfeger

- Original message -
From: Alexander Surkov 
To: Brett Lewis 
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org"
, "jdi...@igalia.com" ,
"accessibility-...@lists.linux-foundation.org"

Subject: Re: Reverse relationships
Date: Wed, Sep 7, 2016 10:34 AM
You're right. An element referred by aria-errormessage can be an
alert of live region and thus should be announced by a screen
reader, when it pops up. In this case, it seems the screen reader
may need to find a context element, and if this is true, then the
reverse relation is needed.
aria-details are different, since they are more like labels and
descriptions, and I guess thus they should be skipped when
navigating the virtual buffer. That suggests that aria-details
either needs a role (or xml-roles object attribute) or a reverse
relation.
On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis > wrote:

Hi,

Is that documented somewhere?

I read through the information on error and I don’t see
anything about AT skipping error messages if encountering them
while reading through the virtual buffer.

Have I misunderstood something?

Thanks,

Brett

*Brett Lewis*

*VFO*| Software Engineer

11800 31^st Court North, St. Petersburg, FL 33716

*T*727-299-6270 

ble...@vfo-group.com 

www.vfo-group.com 

*From:*Alexander Surkov [mailto:surkov.alexan...@gmail.com
]
*Sent:* Wednesday, September 07, 2016 8:02 AM
*To:* Brett Lewis >
*Cc:* Richard Schwerdtfeger >; ja...@nvaccess.org
; jdi...@igalia.com
;
accessibility-...@lists.linux-foundation.org

*Subject:* Re: Reverse relationships

Hi, Brett.

Can you please elaborate your use case? My understanding is AT
skips error/details, if the user encounters them, but announce
them, when the user navigates to an element related with
error/details. Why would AT need to find a related element by
error/details?

Thanks.

Alex.

On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis
> wrote:

Hi Rich,

I think we do need the reverse relationships.

Web authors can place the error/details anywhere on the
page and there doesn’t seem to be any simple way for the
user to determine what element the error message or
details applies to without such a reverse relation.

Brett

*Brett Lewis*

*VFO*| Software Engineer

11800 31^st Court North, St. Petersburg, FL 33716

*T*727-299-6270 

ble...@vfo-group.com 

www.vfo-group.com 

*From:*Richard Schwerdtfeger [mailto:sch...@us.ibm.com
]
*Sent:* Tuesday, September 06, 2016 12:57 PM
*To:* ja...@nvaccess.org ;
surkov.alexan...@gmail.com
; Brett Lewis
>;
jdi...@igalia.com 
*Cc:* accessibility-...@lists.linux-foundation.org

*Subject:* Reverse relationships

We need agreement:

Should the error message and details 

Re: [Accessibility-ia2] Form role mapping

[Richard Schwerdtfeger]

>*AT and browsers support those roles, if Firefox Nightly starts to expose IA2_ROLE_LANDMARK instead IA2_ROLE_FORM, then it >breaks all existing screen reader versions. In case of commercial screen readers this is painful for the users, since they have to buy a >new version of their screen reader. 
Good point. I will switch back to IA2_ROLE_FORM for forms. We still need IA2_ROLE_LANDMARK for the other land marks.
 
Rich
 
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov To: James Teh Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Brett Lewis , Joanmarie Diggs , IAccessible2 mailing list Subject: Re: Form role mappingDate: Wed, Sep 7, 2016 10:58 AM 
There's a point in discussing, the spec can be changed, if there's solid ground for that.My concerns are: * Both IA2 and ATK have a better role match for both role='form' and HTML form, which is ATK_ROLE_FORM and IA2_ROLE_FORM. Thus if there's no strong reason why we have to use a 'weaker' role, then I'd say we should go with the match. * AT and browsers support those roles, if Firefox Nightly starts to expose IA2_ROLE_LANDMARK instead IA2_ROLE_FORM, then it breaks all existing screen reader versions. In case of commercial screen readers this is painful for the users, since they have to buy a new version of their screen reader. * I'm not certain if changing IA2_ROLE_FORM to IA2_ROLE_LANDMARK adds any benefits for screen readers. I'd be curious to hear about them.
 
On Tue, Sep 6, 2016 at 7:15 PM, James Teh  wrote:

Hi Rich,
 
I've already stated my view on this:
 
 
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 spec already requires this, I guess we have little choice but to comply at this stage. 

 At the end of the day, I'm not sure why this is still an open question, since it seems that the spec groups have already made a decision on this: 
The HTML the form element now uses the ARIA mappings for the form role. See "Use WAI-ARIA mapping” under the form element. This is for all platforms.In other words, we can't comply with the spec unless we do as you suggest, so there is no other choice. There is no point in discussing this further.Thanks,Jamie
 
On 7/09/2016 5:54 AM, Richard Schwerdtfeger wrote:
Jamie, Alex, Brett,
 
We need to reach consensus on the  element and role="form" mapping.
 
Can we agree on the following? :
 
1. that the IA2 IDL supports IA2_ROLE_LANDMARK and IA2_ROLE_FORM (so that old versions of FF and other applications using the form role can still work with ATs)
2. For Firefox updates here on out the  element and role="form" map to IA2_ROLE_LANDMARK and xml-roles="form"
 
This way AT vendors can check if something is a landmark to determine if something is a landmark and then expose xml-roles="form"
 
Eventually, it would be better to not have to make an exception for the Form role when all the other landmark roles are represented as IA2_ROLE_LANDMARK with xml-roles="form"
 
This and the other discussion items of the last 2 weeks are holding up 3 working groups - ARIA, HTML, and SVG.
 
Rich Schwerdtfeger
--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org 
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[Richard Schwerdtfeger]

Yes it may provide alternative content as well.
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov To: James Teh Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, IAccessible2 mailing list , Brett Lewis , Joanmarie Diggs , Dominic Mazzoni Subject: Re: Agreement on concatenation of aria-describedby and aria-errormessage relationshipsDate: Wed, Sep 7, 2016 11:15 AM 
Shouldn't it be same speed as walking the virtual buffer? I assume aria-details may contain complex content, for example Pythagorean Theorem from [1], that may be not suitable for stringification in general.[1] https://www.w3.org/TR/wai-aria-1.1/#aria-details
 
On Tue, Sep 6, 2016 at 11:31 PM, James Teh  wrote:

That doesn't solve the need to walk the tree to gather the error message, which is the real problem.
 
On 7/09/2016 12:21 PM, Richard Schwerdtfeger wrote:
I think Dominic's suggestion on an interface tester with bit flags works well.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: James Teh To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: Accessibility-ia2@lists.linux-foundation.orgSubject: Re: Agreement on concatenation of aria-describedby and aria-errormessage relationshipsDate: Tue, Sep 6, 2016 7:19 PM 
Fair enough. Thanks for the clear reasoning.
 
My one remaining concern is performance, but we will clearly need to find an alternative technical solution to this problem. In short, not concatenating means that for every focus event, we need to check for the invalid state plus an errormessage relation and then, if one is found, walk the tree for the target to gather the message. The latter in particular could be unacceptably slow. 

On 7/09/2016 6:35 AM, Richard Schwerdtfeger wrote:
 
The ARIA working group is against concatenating the description and relationship strings. I will try to summarize:
 
Specifically, concatenation by browsers could:
 
Defeat the purposes of aria-errormessage. The aria-errormessage relationship is designed to ensure assistive technology users are as aware of error messages as other users and to enable them to distinguish between error messages and field descriptions. The constraints of ARIA 1.0, and every other accessibility standard and API that preceded it, have forced developers to blend error messages and field descriptions. This blending has long inhibited both the perception and understanding of error messages, which are critical to effective operation of many user interfaces.increase cognitive load for users when errors are present. Especially for screen reader users, we already have severe challenges with excess verbosity that forces the user to expend energy sorting out the most important aspects of screen reader feedback. Concatenating potentially very disparate content in this manner would aggravate the verbosity problem.Reduce assistive technology flexibility. Part of the power of ARIA is that it gives assistive technologies the ability to present content in the manner best suited for their target audiences. When browsers eliminate semantically relevant distinctions, this type of flexibility is diminished. If this concatenation were performed, it would essentially eliminate the semantic distinctions.  If an assistive technology developer wanted to present the field description separate from the error messages, the developer would be forced to ignore the browser-computed description when error messages are present and reconstruct the description computation within the assistive technology.Lead either browsers or authors to devise their own string-based tokenization capability. Because aria-errormessage is a separate relationship, there will be designers and developers who want to ensure there is a method for parsing the string into its separate components. This would reduce the robustness of the solution and create both inconsistencies and complexity, especially when localizing implementations.Introduce serious problems with globalization: namely there is no clean way to concatenate the 2 strings in a way that will make sense. We cannot put in a space as some languages don't have them (Mandarin). Concatenating them together does not read properly.
 
The aria-errormessage relationship is intended to address long-standing accessibility issues faced by both developers and end users. The energy required to find effective remedies to those issues will definitely pay dividends for assistive technology users.
 
Would each of you weigh in. Again this is now holding up 3 working groups going on 3 weeks now.  Do we agree on not concatenating the two strings?
 
Rich
 
Rich Schwerdtfeger 

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 

Re: [Accessibility-ia2] Reverse relationships

[Richard Schwerdtfeger]

Hi Alex,
 
Correct, aria-details requires no special role. However, the use case is for the digital publishing industry. They want to be able to take a piece of content and go to the alternative content that provides detailed information which could be alternative content as we discussed previously. The user may or may not wish to go back to the content the details is being provided for.
 
The need for a reverse relationship for the error message is more critical.
 
So, do we agree on a reverse relationship for error message and not details?
 
Rich Schwerdtfeger
 
 
- Original message -From: Alexander Surkov To: Brett Lewis Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, "ja...@nvaccess.org" , "jdi...@igalia.com" , "accessibility-...@lists.linux-foundation.org" Subject: Re: Reverse relationshipsDate: Wed, Sep 7, 2016 10:34 AM 
You're right. An element referred by aria-errormessage can be an alert of live region and thus should be announced by a screen reader, when it pops up. In this case, it seems the screen reader may need to find a context element, and if this is true, then the reverse relation is needed. 
aria-details are different, since they are more like labels and descriptions, and I guess thus they should be skipped when navigating the virtual buffer. That suggests that aria-details either needs a role (or xml-roles object attribute) or a reverse relation.
 
On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis  wrote:

Hi,
Is that documented somewhere?
I read through the information on error and I don’t see anything about AT skipping error messages if encountering them while reading through the virtual buffer.
Have I misunderstood something?
Thanks,
Brett
 
Brett Lewis
VFO | Software Engineer
11800 31st Court North, St. Petersburg, FL 33716
T 727-299-6270
blewis@vfo-group.com
www.vfo-group.com
 
 
From: Alexander Surkov [mailto:surkov.alexander@gmail.com]Sent: Wednesday, September 07, 2016 8:02 AMTo: Brett Lewis Cc: Richard Schwerdtfeger ; ja...@nvaccess.org; jdi...@igalia.com; Accessibility-ia2@lists.linux-foundation.orgSubject: Re: Reverse relationships
 
Hi, Brett.
Can you please elaborate your use case? My understanding is AT skips error/details, if the user encounters them, but announce them, when the user navigates to an element related with error/details. Why would AT need to find a related element by error/details?
Thanks.
Alex.
 
On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis  wrote:
Hi Rich,
I think we do need the reverse relationships.
Web authors can place the error/details anywhere on the page and there doesn’t seem to be any simple way for the user to determine what element the error message or details applies to without such a reverse relation.
Brett
 
 
Brett Lewis
VFO | Software Engineer
11800 31st Court North, St. Petersburg, FL 33716
T 727-299-6270
blewis@vfo-group.com
www.vfo-group.com
 
 
From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com]Sent: Tuesday, September 06, 2016 12:57 PMTo: ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis ; jdi...@igalia.comCc:  Accessibility-ia2@lists.linux-foundation.orgSubject: Reverse relationships
 
We need agreement:
 
Should the error message and details relationships have reverse mappings?
 
Rich
 
Rich Schwerdtfeger
 
 
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Bitmask for rare accessibility attributes

[Alexander Surkov]

I'd say the bitmask idea is covered by states concept, for example, see
STATE_SYSTEM_HASPOPUP [1]. I guess we can add more IA2 states if needed.

[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373609(v=vs.85).aspx

On Tue, Sep 6, 2016 at 8:39 PM, James Teh  wrote:

> That's a very interesting idea.
>
>
> Note that for errormessage, we can first test for the invalid state, so
> this wouldn't help that. (The bigger problem there is walking the tree to
> get the message from the target.)
>
> What do you think about using an object attribute (or attributes) to do
> this, rather than a separate bit mask? That way, it's much easier to add
> new ones. Also, I'm guessing most AT (certainly screen readers) already
> have to fetch attributes anyway, so this avoids an extra call.
>
> Thanks!
>
> Jamie
>
>
> On 7/09/2016 8:42 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
>
> One of the objections Jamie brought up to making aria-errormessage an
> additional interface is that it increases the number of interfaces AT needs
> to call on every single accessible. I've also thought about this same
> issue, as the number of nodes in an average web page continues to grow
> along with the number of interfaces in IA2.
>
> What would folks think of adding some sort of bitmask to allow AT to
> quickly test for the presence of lots of properties at the same time?
> Something like:
>
> HRESULT propertyBitmask([out, retval] IA2PropertyBitmask *bitmask)
>
> enum   IA2PropertyBitmask {
>   IA2_HAS_NAME = 0x01,
>   IA2_HAS_DESCRIPTION = 0x02,
>   IA2_HAS_ERRORMESSAGE = 0x04,
>   ...
> }
>
> One could imagine variants of this, for example AT could fill in the
> bitmask with properties it's interested in, and the browser would only have
> to compute those.
>
> - Dominic
>
>
>
> ___
> Accessibility-ia2 mailing 
> listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Agreement on concatenation of aria-describedby and aria-errormessage relationships

[Brett Lewis]

Hi Rich,
I think you nicely articulated our concerns w/r/t the concatenation of 
error/description information.
In particular, it is really hard to separate out error information from a 
description if the user wants it for some reason while concatenating the 
information is not too difficult.
Let’s not concatenate.
Brett


Brett Lewis
VFO | Software Engineer
11800 31st Court North, St. Petersburg, FL 33716
T 727-299-6270
ble...@vfo-group.com
www.vfo-group.com


From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
Sent: Tuesday, September 06, 2016 1:36 PM
To: ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis 
; jdi...@igalia.com
Cc: accessibility-...@lists.linux-foundation.org
Subject: Agreement on concatenation of aria-describedby and aria-errormessage 
relationships


The ARIA working group is against concatenating the description and 
relationship strings. I will try to summarize:

Specifically, concatenation by browsers could:


  1.  Defeat the purposes of aria-errormessage. The aria-errormessage 
relationship is designed to ensure assistive technology users are as aware of 
error messages as other users and to enable them to distinguish between error 
messages and field descriptions. The constraints of ARIA 1.0, and every other 
accessibility standard and API that preceded it, have forced developers to 
blend error messages and field descriptions. This blending has long inhibited 
both the perception and understanding of error messages, which are critical to 
effective operation of many user interfaces.
  2.  increase cognitive load for users when errors are present. Especially for 
screen reader users, we already have severe challenges with excess verbosity 
that forces the user to expend energy sorting out the most important aspects of 
screen reader feedback. Concatenating potentially very disparate content in 
this manner would aggravate the verbosity problem.
  3.  Reduce assistive technology flexibility. Part of the power of ARIA is 
that it gives assistive technologies the ability to present content in the 
manner best suited for their target audiences. When browsers eliminate 
semantically relevant distinctions, this type of flexibility is diminished. If 
this concatenation were performed, it would essentially eliminate the semantic 
distinctions.  If an assistive technology developer wanted to present the field 
description separate from the error messages, the developer would be forced to 
ignore the browser-computed description when error messages are present and 
reconstruct the description computation within the assistive technology.
  4.  Lead either browsers or authors to devise their own string-based 
tokenization capability. Because aria-errormessage is a separate relationship, 
there will be designers and developers who want to ensure there is a method for 
parsing the string into its separate components. This would reduce the 
robustness of the solution and create both inconsistencies and complexity, 
especially when localizing implementations.
  5.  Introduce serious problems with globalization: namely there is no clean 
way to concatenate the 2 strings in a way that will make sense. We cannot put 
in a space as some languages don't have them (Mandarin). Concatenating them 
together does not read properly.

The aria-errormessage relationship is intended to address long-standing 
accessibility issues faced by both developers and end users. The energy 
required to find effective remedies to those issues will definitely pay 
dividends for assistive technology users.

Would each of you weigh in. Again this is now holding up 3 working groups going 
on 3 weeks now.  Do we agree on not concatenating the two strings?

Rich



Rich Schwerdtfeger

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Form role mapping

[Brett Lewis]

Hi Rich,
I think this is fine.
This seems like a reasonable way to move forward.
Brett


Brett Lewis
VFO | Software Engineer
11800 31st Court North, St. Petersburg, FL 33716
T 727-299-6270
ble...@vfo-group.com
www.vfo-group.com


From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
Sent: Tuesday, September 06, 2016 12:55 PM
To: ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis 
; jdi...@igalia.com
Cc: accessibility-...@lists.linux-foundation.org
Subject: Form role mapping

Jamie, Alex, Brett,

We need to reach consensus on the  element and role="form" mapping.

Can we agree on the following? :

1. that the IA2 IDL supports IA2_ROLE_LANDMARK and IA2_ROLE_FORM (so that old 
versions of FF and other applications using the form role can still work with 
ATs)
2. For Firefox updates here on out the  element and role="form" map to 
IA2_ROLE_LANDMARK and xml-roles="form"

This way AT vendors can check if something is a landmark to determine if 
something is a landmark and then expose xml-roles="form"

Eventually, it would be better to not have to make an exception for the Form 
role when all the other landmark roles are represented as IA2_ROLE_LANDMARK 
with xml-roles="form"

This and the other discussion items of the last 2 weeks are holding up 3 
working groups - ARIA, HTML, and SVG.



Rich Schwerdtfeger

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Brett Lewis]

Hi,
Is that documented somewhere?
I read through the information on error and I don’t see anything about AT 
skipping error messages if encountering them while reading through the virtual 
buffer.
Have I misunderstood something?
Thanks,
Brett

Brett Lewis
VFO | Software Engineer
11800 31st Court North, St. Petersburg, FL 33716
T 727-299-6270
ble...@vfo-group.com
www.vfo-group.com


From: Alexander Surkov [mailto:surkov.alexan...@gmail.com]
Sent: Wednesday, September 07, 2016 8:02 AM
To: Brett Lewis 
Cc: Richard Schwerdtfeger ; ja...@nvaccess.org; 
jdi...@igalia.com; accessibility-...@lists.linux-foundation.org
Subject: Re: Reverse relationships

Hi, Brett.
Can you please elaborate your use case? My understanding is AT skips 
error/details, if the user encounters them, but announce them, when the user 
navigates to an element related with error/details. Why would AT need to find a 
related element by error/details?
Thanks.
Alex.

On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis 
> wrote:
Hi Rich,
I think we do need the reverse relationships.
Web authors can place the error/details anywhere on the page and there doesn’t 
seem to be any simple way for the user to determine what element the error 
message or details applies to without such a reverse relation.
Brett


Brett Lewis
VFO | Software Engineer
11800 31st Court North, St. Petersburg, FL 33716
T 727-299-6270
ble...@vfo-group.com
www.vfo-group.com


From: Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
Sent: Tuesday, September 06, 2016 12:57 PM
To: ja...@nvaccess.org; 
surkov.alexan...@gmail.com; Brett Lewis 
>; 
jdi...@igalia.com
Cc: 
accessibility-...@lists.linux-foundation.org
Subject: Reverse relationships

We need agreement:

Should the error message and details relationships have reverse mappings?

Rich



Rich Schwerdtfeger


___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Form role mapping

[Alexander Surkov]

There's a point in discussing, the spec can be changed, if there's solid
ground for that.

My concerns are:

* Both IA2 and ATK have a better role match for both role='form' and HTML
form, which is ATK_ROLE_FORM and IA2_ROLE_FORM. Thus if there's no strong
reason why we have to use a 'weaker' role, then I'd say we should go with
the match.

* AT and browsers support those roles, if Firefox Nightly starts to expose
IA2_ROLE_LANDMARK instead IA2_ROLE_FORM, then it breaks all existing screen
reader versions. In case of commercial screen readers this is painful for
the users, since they have to buy a new version of their screen reader.

* I'm not certain if changing IA2_ROLE_FORM to IA2_ROLE_LANDMARK adds any
benefits for screen readers. I'd be curious to hear about them.

On Tue, Sep 6, 2016 at 7:15 PM, James Teh  wrote:

> Hi Rich,
>
>
> I've already stated my view on this:
>
>
> 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 spec already
> requires this, I guess we have little choice but to comply at this stage.
>
>
>
> At the end of the day, I'm not sure why this is still an open question,
> since it seems that the spec groups have already made a decision on this:
>
> The HTML the form element now uses the ARIA mappings for the form role.
> See "Use WAI-ARIA mapping” under the form element. This is for all
> platforms.
>
>
> In other words, we can't comply with the spec unless we do as you suggest,
> so there is no other choice. There is no point in discussing this further.
>
> Thanks,
> Jamie
>
>
> On 7/09/2016 5:54 AM, Richard Schwerdtfeger wrote:
>
> Jamie, Alex, Brett,
>
> We need to reach consensus on the  element and role="form" mapping.
>
> Can we agree on the following? :
>
> 1. that the IA2 IDL supports IA2_ROLE_LANDMARK and IA2_ROLE_FORM (so that
> old versions of FF and other applications using the form role can still
> work with ATs)
> 2. For Firefox updates here on out the  element and role="form" map
> to IA2_ROLE_LANDMARK and xml-roles="form"
>
> This way AT vendors can check if something is a landmark to determine if
> something is a landmark and then expose xml-roles="form"
>
> Eventually, it would be better to not have to make an exception for the
> Form role when all the other landmark roles are represented as
> IA2_ROLE_LANDMARK with xml-roles="form"
>
> This and the other discussion items of the last 2 weeks are holding up 3
> working groups - ARIA, HTML, and SVG.
>
>
>
> Rich Schwerdtfeger
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

You're right. An element referred by aria-errormessage can be an alert of
live region and thus should be announced by a screen reader, when it pops
up. In this case, it seems the screen reader may need to find a context
element, and if this is true, then the reverse relation is needed.

aria-details are different, since they are more like labels and
descriptions, and I guess thus they should be skipped when navigating the
virtual buffer. That suggests that aria-details either needs a role (or
xml-roles object attribute) or a reverse relation.

On Wed, Sep 7, 2016 at 11:11 AM, Brett Lewis  wrote:

> Hi,
>
> Is that documented somewhere?
>
> I read through the information on error and I don’t see anything about AT
> skipping error messages if encountering them while reading through the
> virtual buffer.
>
> Have I misunderstood something?
>
> Thanks,
>
> Brett
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com]
> *Sent:* Wednesday, September 07, 2016 8:02 AM
> *To:* Brett Lewis 
> *Cc:* Richard Schwerdtfeger ; ja...@nvaccess.org;
> jdi...@igalia.com; accessibility-...@lists.linux-foundation.org
> *Subject:* Re: Reverse relationships
>
>
>
> Hi, Brett.
>
> Can you please elaborate your use case? My understanding is AT skips
> error/details, if the user encounters them, but announce them, when the
> user navigates to an element related with error/details. Why would AT need
> to find a related element by error/details?
>
> Thanks.
>
> Alex.
>
>
>
> On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis  wrote:
>
> Hi Rich,
>
> I think we do need the reverse relationships.
>
> Web authors can place the error/details anywhere on the page and there
> doesn’t seem to be any simple way for the user to determine what element
> the error message or details applies to without such a reverse relation.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
> *Sent:* Tuesday, September 06, 2016 12:57 PM
> *To:* ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <
> ble...@vfo-group.com>; jdi...@igalia.com
> *Cc:* accessibility-...@lists.linux-foundation.org
> *Subject:* Reverse relationships
>
>
>
> We need agreement:
>
>
>
> Should the error message and details relationships have reverse mappings?
>
>
>
> Rich
>
>
>
>
>
> Rich Schwerdtfeger
>
>
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

I'd say we need have the reverse relations in both of specs (IA2 and UAIG)
and implemented in the browsers, iff there's a valid use case for them, and
intentions from screen readers to implement them.

On Wed, Sep 7, 2016 at 8:44 AM, Richard Schwerdtfeger 
wrote:

> To be clear, we would not document them in the mapping specification if
> they are not implemented.
>
> When I say add them later I am referring to the mapping spec. and
> browsers. However, doing that has ramifications for AT vendors.
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: James Teh 
> To: Dominic Mazzoni , Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Cc: accessibility-...@lists.linux-foundation.org
> Subject: Re: [Accessibility-ia2] Reverse relationships
> Date: Wed, Sep 7, 2016 12:26 AM
>
>
> That's fair. The only problem is that if they're documented in the mapping
> spec, browsers are technically non-compliant if they don't implement.
>
> On 7/09/2016 2:58 PM, Dominic Mazzoni wrote:
>
> Is there any reason we shouldn't *define* the reverse relationships now?
> Browsers can choose not to implement them now for performance reasons, and
> AT can choose to ignore them.
>
>
> On Tue, Sep 6, 2016 at 7:16 PM Richard Schwerdtfeger 
> wrote:
>
> Jamie,
>
>
> Well you can add reverse relationships later if it becomes an issue. The
> only problem with adding it later is you will also then need to test if
> that reverse relation ship exists and what to do with older browsers that
> won't have the relationship.
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
>
> - Original message -
> From: James Teh 
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com,
> ble...@freedomscientific.com, jdi...@igalia.com
> Cc: accessibility-...@lists.linux-foundation.org
> Subject: Re: Reverse relationships
> Date: Tue, Sep 6, 2016 7:34 PM
>
>
> As I noted previously:
>
>
>
>
>
> 5. Reverse relations may well be useful in the future. However, if they're
> a potential perf problem, I agree it makes sense to wait until we have a
> use case, so long as implementers accept that this use case may one day
> arise.
>
>
>
>
>
> Right now, we have no plans to implement a "jump to field for error
> message" command or similar. Perhaps we will one day, but it seems flawed
> to sacrifice performance for something no one is using yet.
>
> Jamie
>
> On 7/09/2016 5:56 AM, Richard Schwerdtfeger wrote:
>
> We need agreement:
>
> Should the error message and details relationships have reverse mappings?
>
> Rich
>
>
>
> Rich Schwerdtfeger
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: ja...@nvaccess.org
>
>
>
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Alexander Surkov]

Hi, Brett.

Can you please elaborate your use case? My understanding is AT skips
error/details, if the user encounters them, but announce them, when the
user navigates to an element related with error/details. Why would AT need
to find a related element by error/details?

Thanks.
Alex.


On Wed, Sep 7, 2016 at 9:42 AM, Brett Lewis  wrote:

> Hi Rich,
>
> I think we do need the reverse relationships.
>
> Web authors can place the error/details anywhere on the page and there
> doesn’t seem to be any simple way for the user to determine what element
> the error message or details applies to without such a reverse relation.
>
> Brett
>
>
>
>
>
> *Brett Lewis*
>
> *VFO* | Software Engineer
>
> 11800 31st Court North, St. Petersburg, FL 33716
>
> *T* 727-299-6270
>
> ble...@vfo-group.com
>
> www.vfo-group.com
>
>
>
>
>
> *From:* Richard Schwerdtfeger [mailto:sch...@us.ibm.com]
> *Sent:* Tuesday, September 06, 2016 12:57 PM
> *To:* ja...@nvaccess.org; surkov.alexan...@gmail.com; Brett Lewis <
> ble...@vfo-group.com>; jdi...@igalia.com
> *Cc:* accessibility-...@lists.linux-foundation.org
> *Subject:* Reverse relationships
>
>
>
> We need agreement:
>
>
>
> Should the error message and details relationships have reverse mappings?
>
>
>
> Rich
>
>
>
>
>
> Rich Schwerdtfeger
>
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Reverse relationships

[Richard Schwerdtfeger]

To be clear, we would not document them in the mapping specification if they are not implemented.
 
When I say add them later I am referring to the mapping spec. and browsers. However, doing that has ramifications for AT vendors.
Rich Schwerdtfeger
 
 
- Original message -From: James Teh To: Dominic Mazzoni , Richard Schwerdtfeger/Austin/IBM@IBMUSCc: accessibility-...@lists.linux-foundation.orgSubject: Re: [Accessibility-ia2] Reverse relationshipsDate: Wed, Sep 7, 2016 12:26 AM 
That's fair. The only problem is that if they're documented in the mapping spec, browsers are technically non-compliant if they don't implement. 

On 7/09/2016 2:58 PM, Dominic Mazzoni wrote:
Is there any reason we shouldn't *define* the reverse relationships now? Browsers can choose not to implement them now for performance reasons, and AT can choose to ignore them.
  

On Tue, Sep 6, 2016 at 7:16 PM Richard Schwerdtfeger  wrote:
Jamie,
 
 
Well you can add reverse relationships later if it becomes an issue. The only problem with adding it later is you will also then need to test if that reverse relation ship exists and what to do with older browsers that won't have the relationship.
 
Rich
 
Rich Schwerdtfeger
 
 
- Original message -From: James Teh To: Richard Schwerdtfeger/Austin/IBM@IBMUS, surkov.alexan...@gmail.com, ble...@freedomscientific.com, jdi...@igalia.comCc: accessibility-...@lists.linux-foundation.orgSubject: Re: Reverse relationshipsDate: Tue, Sep 6, 2016 7:34 PM 
As I noted previously:
 
 
5. Reverse relations may well be useful in the future. However, if they're a potential perf problem, I agree it makes sense to wait until we have a use case, so long as implementers accept that this use case may one day arise. 

 Right now, we have no plans to implement a "jump to field for error message" command or similar. Perhaps we will one day, but it seems flawed to sacrifice performance for something no one is using yet.Jamie 
On 7/09/2016 5:56 AM, Richard Schwerdtfeger wrote:
We need agreement:
 
Should the error message and details relationships have reverse mappings?
 
Rich
 
Rich Schwerdtfeger 

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org
 ___Accessibility-ia2 mailing listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 

--James TehExecutive Director, NV Access LimitedPh +61 7 3149 3306www.nvaccess.orgFacebook: http://www.facebook.com/NVAccessTwitter: @NVAccessSIP: ja...@nvaccess.org
 

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2