E-mail List Archives
Thread: How to solve a talkback chrome issue for aria-describedby
Number of posts in this thread: 11 (In chronological order)
From: terrence v
Date: Thu, Dec 22 2016 12:42PM
Subject: How to solve a talkback chrome issue for aria-describedby
No previous message | Next message →
Hello,
I am having an issue with aria-deacribedby being read for android talkback
on the chrome browser when the user focuss on the field.
It seems to work for an input type text without a placeholder but does not
read it if the input has a placeholder text or is a select control.
It work on iOS , jaws and NVDA, is there any way I can fix this for android
chrome witouth breaking it for the others.
Here is a an example of a working field and 2 problem fields.
http://output.jsbin.com/tozacusoci
If the link does not work below is the code snippet
<strong>Works</strong>
<div>
<label for='username' >username</label>
<input id='username' type="text" aria-describedby="worksError"
aria-invalid="true"/>
<div id="worksError" class="errorText" aria-live="polite">error
please enter a value</div>
</div>
<strong>does not work</strong>
<div>
<label for='email'>Email</label>
<input id='email' type="text" placeholder=" = EMAIL ADDRESS REMOVED = "
aria-describedby="emailError" aria-invalid="true"/>
<div id="emailError" class="errorText" aria-live="polite">error
please fill in a valid username</div>
</div>
<div>
<label for='year'>Year</label>
<select id='year' aria-describedby="yearError" aria-invalid="true">
<option value="">select year</option>
<option value="2016">2016</option>
<option value="2017">2017</option>
</select>
<div id="yearError" class="errorText" aria-live="polite">error please
select a year</div>
</div>
From: Birkir R. Gunnarsson
Date: Fri, Dec 23 2016 10:58AM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | Next message →
Sounds like a Chrome bug.
I know placeholder maps to an element´s accessible description, but I
am not sure waht hapens when you have multipl sources o accessible
escription. I would they they all map, but in this case the second
source isn´t getting mapped.
On 12/22/16, terrence v < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> I am having an issue with aria-deacribedby being read for android talkback
> on the chrome browser when the user focuss on the field.
>
> It seems to work for an input type text without a placeholder but does not
> read it if the input has a placeholder text or is a select control.
>
> It work on iOS , jaws and NVDA, is there any way I can fix this for android
> chrome witouth breaking it for the others.
>
> Here is a an example of a working field and 2 problem fields.
>
> http://output.jsbin.com/tozacusoci
>
> If the link does not work below is the code snippet
>
> <strong>Works</strong>
> <div>
> <label for='username' >username</label>
> <input id='username' type="text" aria-describedby="worksError"
> aria-invalid="true"/>
> <div id="worksError" class="errorText" aria-live="polite">error
> please enter a value</div>
> </div>
>
>
> <strong>does not work</strong>
> <div>
> <label for='email'>Email</label>
> <input id='email' type="text" placeholder=" = EMAIL ADDRESS REMOVED = "
> aria-describedby="emailError" aria-invalid="true"/>
> <div id="emailError" class="errorText" aria-live="polite">error
> please fill in a valid username</div>
> </div>
>
> <div>
> <label for='year'>Year</label>
> <select id='year' aria-describedby="yearError" aria-invalid="true">
> <option value="">select year</option>
> <option value="2016">2016</option>
> <option value="2017">2017</option>
> </select>
> <div id="yearError" class="errorText" aria-live="polite">error please
> select a year</div>
> </div>
> > > > >
--
Work hard. Have fun. Make history.
From: Birkir R. Gunnarsson
Date: Fri, Dec 23 2016 11:02AM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | Next message →
The new ARIA 1.1 construct for error messages is to put
aria-invalid="tru" and aria-errormessage="id of error message
element", on the input. But I doubt there is much, if any, support for
this yet.
On 12/23/16, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Sounds like a Chrome bug.
> I know placeholder maps to an element´s accessible description, but I
> am not sure waht hapens when you have multipl sources o accessible
> escription. I would they they all map, but in this case the second
> source isn´t getting mapped.
>
>
>
> On 12/22/16, terrence v < = EMAIL ADDRESS REMOVED = > wrote:
>> Hello,
>>
>> I am having an issue with aria-deacribedby being read for android
>> talkback
>> on the chrome browser when the user focuss on the field.
>>
>> It seems to work for an input type text without a placeholder but does
>> not
>> read it if the input has a placeholder text or is a select control.
>>
>> It work on iOS , jaws and NVDA, is there any way I can fix this for
>> android
>> chrome witouth breaking it for the others.
>>
>> Here is a an example of a working field and 2 problem fields.
>>
>> http://output.jsbin.com/tozacusoci
>>
>> If the link does not work below is the code snippet
>>
>> <strong>Works</strong>
>> <div>
>> <label for='username' >username</label>
>> <input id='username' type="text" aria-describedby="worksError"
>> aria-invalid="true"/>
>> <div id="worksError" class="errorText" aria-live="polite">error
>> please enter a value</div>
>> </div>
>>
>>
>> <strong>does not work</strong>
>> <div>
>> <label for='email'>Email</label>
>> <input id='email' type="text" placeholder=" = EMAIL ADDRESS REMOVED = "
>> aria-describedby="emailError" aria-invalid="true"/>
>> <div id="emailError" class="errorText" aria-live="polite">error
>> please fill in a valid username</div>
>> </div>
>>
>> <div>
>> <label for='year'>Year</label>
>> <select id='year' aria-describedby="yearError" aria-invalid="true">
>> <option value="">select year</option>
>> <option value="2016">2016</option>
>> <option value="2017">2017</option>
>> </select>
>> <div id="yearError" class="errorText" aria-live="polite">error
>> please
>> select a year</div>
>> </div>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
>
--
Work hard. Have fun. Make history.
From: Moore,Michael (Accessibility) (HHSC)
Date: Fri, Dec 23 2016 11:09AM
Subject: Re: How to solve a talkback chrome issue foraria-describedby
← Previous message | Next message →
What if you added an aria-describedby="id of error message" to the construct as a backup? - there would probably be a risk of repeating the error message but at least it would be read. I don't suppose polyfill methods would work for this?
Mike Moore
EIR (Electronic Information Resoources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)
Making electronic information and services accessible to people with disabilities is everyone's job. I am here to help.
From: terrence v
Date: Fri, Dec 23 2016 11:38AM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | Next message →
could you shed some light what it looks like in code to assign to the
construct , sorry I did not understand that clearly.
On Dec 23, 2016 10:09 AM, "Moore,Michael (Accessibility) (HHSC)" <
= EMAIL ADDRESS REMOVED = > wrote:
What if you added an aria-describedby="id of error message" to the
construct as a backup? - there would probably be a risk of repeating the
error message but at least it would be read. I don't suppose polyfill
methods would work for this?
Mike Moore
EIR (Electronic Information Resoources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)
Making electronic information and services accessible to people with
disabilities is everyone's job. I am here to help.
From: terrence v
Date: Fri, Dec 23 2016 11:45AM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | Next message →
yes looks like a chrome bug , seems to work fine fiefox ,but looking for a
android chrome solution which does not break break voiceover, jaws or nvda,
has to work well with them.
On Dec 23, 2016 9:58 AM, "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
wrote:
> Sounds like a Chrome bug.
> I know placeholder maps to an element´s accessible description, but I
> am not sure waht hapens when you have multipl sources o accessible
> escription. I would they they all map, but in this case the second
> source isn´t getting mapped.
>
>
>
> On 12/22/16, terrence v < = EMAIL ADDRESS REMOVED = > wrote:
> > Hello,
> >
> > I am having an issue with aria-deacribedby being read for android
> talkback
> > on the chrome browser when the user focuss on the field.
> >
> > It seems to work for an input type text without a placeholder but does
> not
> > read it if the input has a placeholder text or is a select control.
> >
> > It work on iOS , jaws and NVDA, is there any way I can fix this for
> android
> > chrome witouth breaking it for the others.
> >
> > Here is a an example of a working field and 2 problem fields.
> >
> > http://output.jsbin.com/tozacusoci
> >
> > If the link does not work below is the code snippet
> >
> > <strong>Works</strong>
> > <div>
> > <label for='username' >username</label>
> > <input id='username' type="text" aria-describedby="worksError"
> > aria-invalid="true"/>
> > <div id="worksError" class="errorText" aria-live="polite">error
> > please enter a value</div>
> > </div>
> >
> >
> > <strong>does not work</strong>
> > <div>
> > <label for='email'>Email</label>
> > <input id='email' type="text" placeholder=" = EMAIL ADDRESS REMOVED = "
> > aria-describedby="emailError" aria-invalid="true"/>
> > <div id="emailError" class="errorText" aria-live="polite">error
> > please fill in a valid username</div>
> > </div>
> >
> > <div>
> > <label for='year'>Year</label>
> > <select id='year' aria-describedby="yearError" aria-invalid="true">
> > <option value="">select year</option>
> > <option value="2016">2016</option>
> > <option value="2017">2017</option>
> > </select>
> > <div id="yearError" class="errorText" aria-live="polite">error
> please
> > select a year</div>
> > </div>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
From: Moore,Michael (Accessibility) (HHSC)
Date: Fri, Dec 23 2016 11:46AM
Subject: Re: How to solve a talkback chrome issue foraria-describedby
← Previous message | Next message →
<input ... aria-invalid="tru" aria-errormessage="error message id" aria-describedby="error message id"...
Mike Moore
EIR (Electronic Information Resoources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)
Making electronic information and services accessible to people with disabilities is everyone's job. I am here to help.
From: terrence v
Date: Fri, Dec 23 2016 11:57AM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | Next message →
Thanks Michael,
Tried aria-errormessage="error message id"
Looks like chrome has issues reading it.
On Dec 23, 2016 10:46 AM, "Moore,Michael (Accessibility) (HHSC)" <
= EMAIL ADDRESS REMOVED = > wrote:
<input ... aria-invalid="tru" aria-errormessage="error message id"
aria-describedby="error message id"...
Mike Moore
EIR (Electronic Information Resoources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)
Making electronic information and services accessible to people with
disabilities is everyone's job. I am here to help.
From: Moore,Michael (Accessibility) (HHSC)
Date: Fri, Dec 23 2016 12:01PM
Subject: Re: How to solve a talkback chrome issue foraria-describedby
← Previous message | Next message →
Yes there is not much support for that attribute at this point aria-describedby provides a backup. IMHO chrome accessibility support in general is not very good for windows based screen readers yet. Ideally the aria-describedby would only be injected when it was needed but I am not sure how well that could be determined.
Mike Moore
EIR (Electronic Information Resoources) Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)
Making electronic information and services accessible to people with disabilities is everyone's job. I am here to help.
From: Birkir R. Gunnarsson
Date: Sat, Dec 24 2016 6:43PM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | Next message →
This is an example as to why you have to pick an accessibility testing
platform, and optimize only for that platform.
I always recommend NVDA with Firefox, because Firefox is responsive to
accessibility pdates and NVDA is free and open source.
Accessibility is not only the webpage author's business. The author
needs to make sure to write standards compliant/accessible code that
works with at least one browser/A.T. combination.
* It is the browser vendor's responsibility to expose the
accessibility markup to the operating system's accessibility API.
* It is the operating system's vendor's job to make sure the API
accommodates all accessibility markup.
* It is the assistive technology maker's job to make sure the a.t.
application queries the interface and interprets the information in a
way the end users can understand.
In this scenario, Google; the vendor responsible for Chrome, is most
likely responsible for not handling aria-describebby properly (not
exposing its value as an accessible description to the Windows
accessibility API, either MSAA, UIA or iAccessible2. I say this
because it works fine with Firefox.
It could also be Windows fault (implementing so many accessibility
interfaces, often failing to implement one all the way).
My point is that the authors are not the only ones responsible for
webpages being accessible in all browsers on all operating systems.
That is the reason we have standards in the first place. The work must
be not only on the authors, but on the browser vendors, the operating
system vendors and the assistive technology vendors.
We have standards to explain how information should be exposed. Those
are not perfect, but we are working hard to improve them.
It is our job, as accessibility experts, to recognize the glitches and
file bugs with the parties we believe are responsible.
We can ask the authors to jump through hoops to address the need, but
if we keep doing that, we will destroy the whole effort of
accessibility standardization.
We have a responsibility to help ensure that accessible markup is
turned into an accessible experience on the largest possible
combination of browsers, operating systems and assistive technologies.
But we can't always do that by asking the webpage developers to jump
through hoops and expose all manners of tricky markup to workaround
the inefficiencies and bugs of this and that browser.
It is our responsibility to make sure it works on at least one
reasonable combination, and then to help file bugs and promote
accessibility everywhere else.
Cheers
-B
On 12/23/16, Moore,Michael (Accessibility) (HHSC)
< = EMAIL ADDRESS REMOVED = > wrote:
> Yes there is not much support for that attribute at this point
> aria-describedby provides a backup. IMHO chrome accessibility support in
> general is not very good for windows based screen readers yet. Ideally the
> aria-describedby would only be injected when it was needed but I am not sure
> how well that could be determined.
>
> Mike Moore
> EIR (Electronic Information Resoources) Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)
>
> Making electronic information and services accessible to people with
> disabilities is everyone's job. I am here to help.
>
>
From: Kevin Chao
Date: Tue, Dec 27 2016 9:04AM
Subject: Re: How to solve a talkback chrome issue for aria-describedby
← Previous message | No next message
Thanks! I've filed a crbug:
https://bugs.chromium.org/p/chromium/issues/detail?idg7147
On Sat, Dec 24, 2016 at 5:43 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> This is an example as to why you have to pick an accessibility testing
> platform, and optimize only for that platform.
>
> I always recommend NVDA with Firefox, because Firefox is responsive to
> accessibility pdates and NVDA is free and open source.
> Accessibility is not only the webpage author's business. The author
> needs to make sure to write standards compliant/accessible code that
> works with at least one browser/A.T. combination.
> * It is the browser vendor's responsibility to expose the
> accessibility markup to the operating system's accessibility API.
> * It is the operating system's vendor's job to make sure the API
> accommodates all accessibility markup.
> * It is the assistive technology maker's job to make sure the a.t.
> application queries the interface and interprets the information in a
> way the end users can understand.
> In this scenario, Google; the vendor responsible for Chrome, is most
> likely responsible for not handling aria-describebby properly (not
> exposing its value as an accessible description to the Windows
> accessibility API, either MSAA, UIA or iAccessible2. I say this
> because it works fine with Firefox.
> It could also be Windows fault (implementing so many accessibility
> interfaces, often failing to implement one all the way).
> My point is that the authors are not the only ones responsible for
> webpages being accessible in all browsers on all operating systems.
> That is the reason we have standards in the first place. The work must
> be not only on the authors, but on the browser vendors, the operating
> system vendors and the assistive technology vendors.
> We have standards to explain how information should be exposed. Those
> are not perfect, but we are working hard to improve them.
> It is our job, as accessibility experts, to recognize the glitches and
> file bugs with the parties we believe are responsible.
> We can ask the authors to jump through hoops to address the need, but
> if we keep doing that, we will destroy the whole effort of
> accessibility standardization.
> We have a responsibility to help ensure that accessible markup is
> turned into an accessible experience on the largest possible
> combination of browsers, operating systems and assistive technologies.
> But we can't always do that by asking the webpage developers to jump
> through hoops and expose all manners of tricky markup to workaround
> the inefficiencies and bugs of this and that browser.
> It is our responsibility to make sure it works on at least one
> reasonable combination, and then to help file bugs and promote
> accessibility everywhere else.
>
> Cheers
> -B
>
>
> On 12/23/16, Moore,Michael (Accessibility) (HHSC)
> < = EMAIL ADDRESS REMOVED = > wrote:
> > Yes there is not much support for that attribute at this point
> > aria-describedby provides a backup. IMHO chrome accessibility support in
> > general is not very good for windows based screen readers yet. Ideally
> the
> > aria-describedby would only be injected when it was needed but I am not
> sure
> > how well that could be determined.
> >
> > Mike Moore
> > EIR (Electronic Information Resoources) Accessibility Coordinator
> > Texas Health and Human Services Commission
> > Civil Rights Office
> > (512) 438-3431 (Office)
> > (512) 574-0091 (Cell)
> >
> > Making electronic information and services accessible to people with
> > disabilities is everyone's job. I am here to help.
> >
> >