E-mail List Archives
Thread: Fwd: Dynamic Form Input Rules
Number of posts in this thread: 8 (In chronological order)
From: Brian Lovely
Date: Wed, Aug 24 2016 11:39AM
Subject: Fwd: Dynamic Form Input Rules
No previous message | Next message →
Sorry about the forward; this isn't sending from my work account
Brian Lovely
= EMAIL ADDRESS REMOVED =
Begin forwarded message:
> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
> Date: August 24, 2016 at 1:37:15 PM EDT
> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
> Subject: FW: Dynamic Form Input Rules
>
>
>
> From: Lovely, Brian (CONT)
> Sent: Wednesday, August 24, 2016 8:56 AM
> To: 'WebAIM Discussion List'
> Subject: Dynamic Form Input Rules
>
> I would like someone who is a screen reader user to tell me what the ideal experience would be for this. Here is the current, less-than-ideal flow:
>
> When a form text input receives focus, the usual stuff is announced. So far, everything is fine. Once you start typing, though, a container appears below the input (after it in code order). The container holds a series of rules regarding the correct format for the input: At least a certain number of characters, no spaces, at least one numeral, there are four or five of these rules. Each rule is preceded by a graphic, either a red "X" or a green checkmark. Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>
> I know this is problematic (for instance, the fulfilled/not-fulfilled state of each rule is not read out), but what would be the ideal way to communicate these kind of rules (for instance, for creating a user name or password)? Feel free to alter/remove the location of the container, the appearing/disappearing of the container, the graphic indicators, etc.
>
> <image001.png>
> Brian Lovely
> Digital Accessibility Team
> = EMAIL ADDRESS REMOVED =
>
>
>
> The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Jamous, JP
Date: Wed, Aug 24 2016 1:36PM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | Next message →
Brian,
I would prefer a link before the text box in the DOM that states, "Read our password policy first."
When I press that link, the cursor gets put in the container at the top of the message. I can down-arrow through it and read it. As soon as I press the Close button, I am returned to the link or the password field.
Please, do not hook the description to aria-describedby when I land on that first text box. You'd tick me off big time.
**************************************************
Jean-Pierre Jamous
Digital Accessibility Specialist & Developer
UI Accessibility Team
The only limitations in life are those we set for ourselves
**************************************************
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Brian Lovely
Sent: Wednesday, August 24, 2016 12:39 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Fwd: Dynamic Form Input Rules
Sorry about the forward; this isn't sending from my work account
Brian Lovely
= EMAIL ADDRESS REMOVED =
Begin forwarded message:
> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
> Date: August 24, 2016 at 1:37:15 PM EDT
> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
> Subject: FW: Dynamic Form Input Rules
>
>
>
> From: Lovely, Brian (CONT)
> Sent: Wednesday, August 24, 2016 8:56 AM
> To: 'WebAIM Discussion List'
> Subject: Dynamic Form Input Rules
>
> I would like someone who is a screen reader user to tell me what the ideal experience would be for this. Here is the current, less-than-ideal flow:
>
> When a form text input receives focus, the usual stuff is announced. So far, everything is fine. Once you start typing, though, a container appears below the input (after it in code order). The container holds a series of rules regarding the correct format for the input: At least a certain number of characters, no spaces, at least one numeral, there are four or five of these rules. Each rule is preceded by a graphic, either a red "X" or a green checkmark. Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>
> I know this is problematic (for instance, the fulfilled/not-fulfilled state of each rule is not read out), but what would be the ideal way to communicate these kind of rules (for instance, for creating a user name or password)? Feel free to alter/remove the location of the container, the appearing/disappearing of the container, the graphic indicators, etc.
>
> <image001.png>
> Brian Lovely
> Digital Accessibility Team
> = EMAIL ADDRESS REMOVED =
>
>
>
> The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Birkir R. Gunnarsson
Date: Wed, Aug 24 2016 3:15PM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | Next message →
I have implemented a dynamic password strength indicator using live
regions. It worked farily well, but needed an awful lot of fine-tuning
for screen reader verbosity.
The idea is to turn the whole strength indicator element into a live
region (putting aria-live="polite").
As images change from "incomplete" to "complete" you update their alt
text o reflect that, and that gets announced by screen readers (most
of them, Jaws does not consider change of alt text content update in a
live region, or just doesn't work).
It is a cool concept, but it did not work consistently across enough
screen reders and browsers to be more than a show piece.
On 8/24/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
> Brian,
>
> I would prefer a link before the text box in the DOM that states, "Read our
> password policy first."
>
> When I press that link, the cursor gets put in the container at the top of
> the message. I can down-arrow through it and read it. As soon as I press the
> Close button, I am returned to the link or the password field.
>
> Please, do not hook the description to aria-describedby when I land on that
> first text box. You'd tick me off big time.
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer
> UI Accessibility Team
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Brian Lovely
> Sent: Wednesday, August 24, 2016 12:39 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Fwd: Dynamic Form Input Rules
>
>
> Sorry about the forward; this isn't sending from my work account
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
> Begin forwarded message:
>
>> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
>> Date: August 24, 2016 at 1:37:15 PM EDT
>> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>> Subject: FW: Dynamic Form Input Rules
>>
>>
>>
>> From: Lovely, Brian (CONT)
>> Sent: Wednesday, August 24, 2016 8:56 AM
>> To: 'WebAIM Discussion List'
>> Subject: Dynamic Form Input Rules
>>
>> I would like someone who is a screen reader user to tell me what the ideal
>> experience would be for this. Here is the current, less-than-ideal flow:
>>
>> When a form text input receives focus, the usual stuff is announced. So
>> far, everything is fine. Once you start typing, though, a container
>> appears below the input (after it in code order). The container holds a
>> series of rules regarding the correct format for the input: At least a
>> certain number of characters, no spaces, at least one numeral, there are
>> four or five of these rules. Each rule is preceded by a graphic, either a
>> red "X" or a green checkmark. Non-fulfilled rules have the "X", fulfilled
>> rules the checkmark. When all rules are met the container disappears.
>>
>> I know this is problematic (for instance, the fulfilled/not-fulfilled
>> state of each rule is not read out), but what would be the ideal way to
>> communicate these kind of rules (for instance, for creating a user name or
>> password)? Feel free to alter/remove the location of the container, the
>> appearing/disappearing of the container, the graphic indicators, etc.
>>
>> <image001.png>
>> Brian Lovely
>> Digital Accessibility Team
>> = EMAIL ADDRESS REMOVED =
>>
>>
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the
>> intended recipient, you are hereby notified that any review,
>> retransmission, dissemination, distribution, copying or other use of, or
>> taking of any action in reliance upon this information is strictly
>> prohibited. If you have received this communication in error, please
>> contact the sender and delete the material from your computer.
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: Lovely, Brian (CONT)
Date: Thu, Aug 25 2016 6:49AM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | Next message →
I have encountered these things as a sighted user, and didn't like the fact that the rules are hidden when you start, and as soon as you start typing, the rules appear. What I find frustrating about these is that I would have typed something else if I had known the rules up front. I also have this problem with phone number inputs that fail your response and only then give you the format they require. If you have rules, just make them visible from the get-go.
My assumption is that a screen reader user would rather be informed of the presence of the rules, and allowed to consume them at their own pace, rather than have them read out. I have no idea if actual user testing would prove that correct or not. Then the changing of the pass/fail state of each rule presents its own problems. You're right, Birkir, verbosity could be a problem if the user is typing while the rules are being announce, and then the changes in pass/fail state.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, August 24, 2016 5:15 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
I have implemented a dynamic password strength indicator using live regions. It worked farily well, but needed an awful lot of fine-tuning for screen reader verbosity.
The idea is to turn the whole strength indicator element into a live region (putting aria-live="polite").
As images change from "incomplete" to "complete" you update their alt text o reflect that, and that gets announced by screen readers (most of them, Jaws does not consider change of alt text content update in a live region, or just doesn't work).
It is a cool concept, but it did not work consistently across enough screen reders and browsers to be more than a show piece.
On 8/24/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
> Brian,
>
> I would prefer a link before the text box in the DOM that states,
> "Read our password policy first."
>
> When I press that link, the cursor gets put in the container at the
> top of the message. I can down-arrow through it and read it. As soon
> as I press the Close button, I am returned to the link or the password field.
>
> Please, do not hook the description to aria-describedby when I land on
> that first text box. You'd tick me off big time.
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer UI Accessibility Team
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Brian Lovely
> Sent: Wednesday, August 24, 2016 12:39 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Fwd: Dynamic Form Input Rules
>
>
> Sorry about the forward; this isn't sending from my work account
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
> Begin forwarded message:
>
>> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
>> Date: August 24, 2016 at 1:37:15 PM EDT
>> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>> Subject: FW: Dynamic Form Input Rules
>>
>>
>>
>> From: Lovely, Brian (CONT)
>> Sent: Wednesday, August 24, 2016 8:56 AM
>> To: 'WebAIM Discussion List'
>> Subject: Dynamic Form Input Rules
>>
>> I would like someone who is a screen reader user to tell me what the
>> ideal experience would be for this. Here is the current, less-than-ideal flow:
>>
>> When a form text input receives focus, the usual stuff is announced.
>> So far, everything is fine. Once you start typing, though, a
>> container appears below the input (after it in code order). The
>> container holds a series of rules regarding the correct format for
>> the input: At least a certain number of characters, no spaces, at
>> least one numeral, there are four or five of these rules. Each rule
>> is preceded by a graphic, either a red "X" or a green checkmark.
>> Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>>
>> I know this is problematic (for instance, the fulfilled/not-fulfilled
>> state of each rule is not read out), but what would be the ideal way
>> to communicate these kind of rules (for instance, for creating a user
>> name or password)? Feel free to alter/remove the location of the
>> container, the appearing/disappearing of the container, the graphic indicators, etc.
>>
>> <image001.png>
>> Brian Lovely
>> Digital Accessibility Team
>> = EMAIL ADDRESS REMOVED =
>>
>>
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The
>> information transmitted herewith is intended only for use by the
>> individual or entity to which it is addressed. If the reader of this
>> message is not the intended recipient, you are hereby notified that
>> any review, retransmission, dissemination, distribution, copying or
>> other use of, or taking of any action in reliance upon this
>> information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Jamous, JP
Date: Thu, Aug 25 2016 7:06AM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | Next message →
That's the problem we face. How do you find that happy medium?
ARIA has its limitations so as Screen Readers. Weeding out those limitations would lead us to 2 conclusions.
1. It can be done
Or
2. It cannot be done and let's create an alternative.
**************************************************
Jean-Pierre Jamous
Digital Accessibility Specialist & Developer
UI Accessibility Team
The only limitations in life are those we set for ourselves
**************************************************
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, August 24, 2016 4:15 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
I have implemented a dynamic password strength indicator using live regions. It worked farily well, but needed an awful lot of fine-tuning for screen reader verbosity.
The idea is to turn the whole strength indicator element into a live region (putting aria-live="polite").
As images change from "incomplete" to "complete" you update their alt text o reflect that, and that gets announced by screen readers (most of them, Jaws does not consider change of alt text content update in a live region, or just doesn't work).
It is a cool concept, but it did not work consistently across enough screen reders and browsers to be more than a show piece.
On 8/24/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
> Brian,
>
> I would prefer a link before the text box in the DOM that states,
> "Read our password policy first."
>
> When I press that link, the cursor gets put in the container at the
> top of the message. I can down-arrow through it and read it. As soon
> as I press the Close button, I am returned to the link or the password field.
>
> Please, do not hook the description to aria-describedby when I land on
> that first text box. You'd tick me off big time.
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer UI Accessibility Team
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Brian Lovely
> Sent: Wednesday, August 24, 2016 12:39 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Fwd: Dynamic Form Input Rules
>
>
> Sorry about the forward; this isn't sending from my work account
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
> Begin forwarded message:
>
>> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
>> Date: August 24, 2016 at 1:37:15 PM EDT
>> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>> Subject: FW: Dynamic Form Input Rules
>>
>>
>>
>> From: Lovely, Brian (CONT)
>> Sent: Wednesday, August 24, 2016 8:56 AM
>> To: 'WebAIM Discussion List'
>> Subject: Dynamic Form Input Rules
>>
>> I would like someone who is a screen reader user to tell me what the
>> ideal experience would be for this. Here is the current, less-than-ideal flow:
>>
>> When a form text input receives focus, the usual stuff is announced.
>> So far, everything is fine. Once you start typing, though, a
>> container appears below the input (after it in code order). The
>> container holds a series of rules regarding the correct format for
>> the input: At least a certain number of characters, no spaces, at
>> least one numeral, there are four or five of these rules. Each rule
>> is preceded by a graphic, either a red "X" or a green checkmark.
>> Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>>
>> I know this is problematic (for instance, the fulfilled/not-fulfilled
>> state of each rule is not read out), but what would be the ideal way
>> to communicate these kind of rules (for instance, for creating a user
>> name or password)? Feel free to alter/remove the location of the
>> container, the appearing/disappearing of the container, the graphic indicators, etc.
>>
>> <image001.png>
>> Brian Lovely
>> Digital Accessibility Team
>> = EMAIL ADDRESS REMOVED =
>>
>>
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The
>> information transmitted herewith is intended only for use by the
>> individual or entity to which it is addressed. If the reader of this
>> message is not the intended recipient, you are hereby notified that
>> any review, retransmission, dissemination, distribution, copying or
>> other use of, or taking of any action in reliance upon this
>> information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
From: Jamous, JP
Date: Thu, Aug 25 2016 7:16AM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | Next message →
Ditto.
I want to know how the text box input should be in the label so I don't have to have the validators firing back on me.
I dislike the fact that certain developers use Placeholders to show you the format. In fact, I am eliminating this at our company. Text Boxes should be empty. MM/DD/YYYY inserted in the text field might seem to a screen reader or a sighted user that this is a read-only text box.
**************************************************
Jean-Pierre Jamous
Digital Accessibility Specialist & Developer
UI Accessibility Team
The only limitations in life are those we set for ourselves
**************************************************
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lovely, Brian (CONT)
Sent: Thursday, August 25, 2016 7:49 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
I have encountered these things as a sighted user, and didn't like the fact that the rules are hidden when you start, and as soon as you start typing, the rules appear. What I find frustrating about these is that I would have typed something else if I had known the rules up front. I also have this problem with phone number inputs that fail your response and only then give you the format they require. If you have rules, just make them visible from the get-go.
My assumption is that a screen reader user would rather be informed of the presence of the rules, and allowed to consume them at their own pace, rather than have them read out. I have no idea if actual user testing would prove that correct or not. Then the changing of the pass/fail state of each rule presents its own problems. You're right, Birkir, verbosity could be a problem if the user is typing while the rules are being announce, and then the changes in pass/fail state.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, August 24, 2016 5:15 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
I have implemented a dynamic password strength indicator using live regions. It worked farily well, but needed an awful lot of fine-tuning for screen reader verbosity.
The idea is to turn the whole strength indicator element into a live region (putting aria-live="polite").
As images change from "incomplete" to "complete" you update their alt text o reflect that, and that gets announced by screen readers (most of them, Jaws does not consider change of alt text content update in a live region, or just doesn't work).
It is a cool concept, but it did not work consistently across enough screen reders and browsers to be more than a show piece.
On 8/24/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
> Brian,
>
> I would prefer a link before the text box in the DOM that states,
> "Read our password policy first."
>
> When I press that link, the cursor gets put in the container at the
> top of the message. I can down-arrow through it and read it. As soon
> as I press the Close button, I am returned to the link or the password field.
>
> Please, do not hook the description to aria-describedby when I land on
> that first text box. You'd tick me off big time.
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer UI Accessibility Team
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Brian Lovely
> Sent: Wednesday, August 24, 2016 12:39 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Fwd: Dynamic Form Input Rules
>
>
> Sorry about the forward; this isn't sending from my work account
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
> Begin forwarded message:
>
>> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
>> Date: August 24, 2016 at 1:37:15 PM EDT
>> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>> Subject: FW: Dynamic Form Input Rules
>>
>>
>>
>> From: Lovely, Brian (CONT)
>> Sent: Wednesday, August 24, 2016 8:56 AM
>> To: 'WebAIM Discussion List'
>> Subject: Dynamic Form Input Rules
>>
>> I would like someone who is a screen reader user to tell me what the
>> ideal experience would be for this. Here is the current, less-than-ideal flow:
>>
>> When a form text input receives focus, the usual stuff is announced.
>> So far, everything is fine. Once you start typing, though, a
>> container appears below the input (after it in code order). The
>> container holds a series of rules regarding the correct format for
>> the input: At least a certain number of characters, no spaces, at
>> least one numeral, there are four or five of these rules. Each rule
>> is preceded by a graphic, either a red "X" or a green checkmark.
>> Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>>
>> I know this is problematic (for instance, the fulfilled/not-fulfilled
>> state of each rule is not read out), but what would be the ideal way
>> to communicate these kind of rules (for instance, for creating a user
>> name or password)? Feel free to alter/remove the location of the
>> container, the appearing/disappearing of the container, the graphic indicators, etc.
>>
>> <image001.png>
>> Brian Lovely
>> Digital Accessibility Team
>> = EMAIL ADDRESS REMOVED =
>>
>>
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The
>> information transmitted herewith is intended only for use by the
>> individual or entity to which it is addressed. If the reader of this
>> message is not the intended recipient, you are hereby notified that
>> any review, retransmission, dissemination, distribution, copying or
>> other use of, or taking of any action in reliance upon this
>> information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Lovely, Brian (CONT)
Date: Thu, Aug 25 2016 7:16AM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | Next message →
Yeah, in this case, I'm leaning towards hidden text alternate. Not my go-to solution, but it might be best in this particular case. A hidden text alternate for an image of text is one thing, a text alternate of a widget is another.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jamous, JP
Sent: Thursday, August 25, 2016 9:07 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
That's the problem we face. How do you find that happy medium?
ARIA has its limitations so as Screen Readers. Weeding out those limitations would lead us to 2 conclusions.
1. It can be done
Or
2. It cannot be done and let's create an alternative.
**************************************************
Jean-Pierre Jamous
Digital Accessibility Specialist & Developer UI Accessibility Team
The only limitations in life are those we set for ourselves
**************************************************
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, August 24, 2016 4:15 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
I have implemented a dynamic password strength indicator using live regions. It worked farily well, but needed an awful lot of fine-tuning for screen reader verbosity.
The idea is to turn the whole strength indicator element into a live region (putting aria-live="polite").
As images change from "incomplete" to "complete" you update their alt text o reflect that, and that gets announced by screen readers (most of them, Jaws does not consider change of alt text content update in a live region, or just doesn't work).
It is a cool concept, but it did not work consistently across enough screen reders and browsers to be more than a show piece.
On 8/24/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
> Brian,
>
> I would prefer a link before the text box in the DOM that states,
> "Read our password policy first."
>
> When I press that link, the cursor gets put in the container at the
> top of the message. I can down-arrow through it and read it. As soon
> as I press the Close button, I am returned to the link or the password field.
>
> Please, do not hook the description to aria-describedby when I land on
> that first text box. You'd tick me off big time.
>
>
>
>
> **************************************************
>
> Jean-Pierre Jamous
> Digital Accessibility Specialist & Developer UI Accessibility Team
>
> The only limitations in life are those we set for ourselves
>
> **************************************************
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Brian Lovely
> Sent: Wednesday, August 24, 2016 12:39 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Fwd: Dynamic Form Input Rules
>
>
> Sorry about the forward; this isn't sending from my work account
>
> Brian Lovely
> = EMAIL ADDRESS REMOVED =
>
> Begin forwarded message:
>
>> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
>> Date: August 24, 2016 at 1:37:15 PM EDT
>> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>> Subject: FW: Dynamic Form Input Rules
>>
>>
>>
>> From: Lovely, Brian (CONT)
>> Sent: Wednesday, August 24, 2016 8:56 AM
>> To: 'WebAIM Discussion List'
>> Subject: Dynamic Form Input Rules
>>
>> I would like someone who is a screen reader user to tell me what the
>> ideal experience would be for this. Here is the current, less-than-ideal flow:
>>
>> When a form text input receives focus, the usual stuff is announced.
>> So far, everything is fine. Once you start typing, though, a
>> container appears below the input (after it in code order). The
>> container holds a series of rules regarding the correct format for
>> the input: At least a certain number of characters, no spaces, at
>> least one numeral, there are four or five of these rules. Each rule
>> is preceded by a graphic, either a red "X" or a green checkmark.
>> Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>>
>> I know this is problematic (for instance, the fulfilled/not-fulfilled
>> state of each rule is not read out), but what would be the ideal way
>> to communicate these kind of rules (for instance, for creating a user
>> name or password)? Feel free to alter/remove the location of the
>> container, the appearing/disappearing of the container, the graphic indicators, etc.
>>
>> <image001.png>
>> Brian Lovely
>> Digital Accessibility Team
>> = EMAIL ADDRESS REMOVED =
>>
>>
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The
>> information transmitted herewith is intended only for use by the
>> individual or entity to which it is addressed. If the reader of this
>> message is not the intended recipient, you are hereby notified that
>> any review, retransmission, dissemination, distribution, copying or
>> other use of, or taking of any action in reliance upon this
>> information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Jonathan Cohn
Date: Thu, Aug 25 2016 7:08AM
Subject: Re: Fwd: Dynamic Form Input Rules
← Previous message | No next message
Could the live region announce you have completed 4 of 5 complexity rules And perhaps have an anchor set to review the rules?
Best wishes,
Jonathan Cohn
> On Aug 25, 2016, at 8:49 AM, Lovely, Brian (CONT) < = EMAIL ADDRESS REMOVED = > wrote:
>
> I have encountered these things as a sighted user, and didn't like the fact that the rules are hidden when you start, and as soon as you start typing, the rules appear. What I find frustrating about these is that I would have typed something else if I had known the rules up front. I also have this problem with phone number inputs that fail your response and only then give you the format they require. If you have rules, just make them visible from the get-go.
>
> My assumption is that a screen reader user would rather be informed of the presence of the rules, and allowed to consume them at their own pace, rather than have them read out. I have no idea if actual user testing would prove that correct or not. Then the changing of the pass/fail state of each rule presents its own problems. You're right, Birkir, verbosity could be a problem if the user is typing while the rules are being announce, and then the changes in pass/fail state.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
> Sent: Wednesday, August 24, 2016 5:15 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Fwd: Dynamic Form Input Rules
>
> I have implemented a dynamic password strength indicator using live regions. It worked farily well, but needed an awful lot of fine-tuning for screen reader verbosity.
> The idea is to turn the whole strength indicator element into a live region (putting aria-live="polite").
> As images change from "incomplete" to "complete" you update their alt text o reflect that, and that gets announced by screen readers (most of them, Jaws does not consider change of alt text content update in a live region, or just doesn't work).
> It is a cool concept, but it did not work consistently across enough screen reders and browsers to be more than a show piece.
>
>
>
> On 8/24/16, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
>> Brian,
>>
>> I would prefer a link before the text box in the DOM that states,
>> "Read our password policy first."
>>
>> When I press that link, the cursor gets put in the container at the
>> top of the message. I can down-arrow through it and read it. As soon
>> as I press the Close button, I am returned to the link or the password field.
>>
>> Please, do not hook the description to aria-describedby when I land on
>> that first text box. You'd tick me off big time.
>>
>>
>>
>>
>> **************************************************
>>
>> Jean-Pierre Jamous
>> Digital Accessibility Specialist & Developer UI Accessibility Team
>>
>> The only limitations in life are those we set for ourselves
>>
>> **************************************************
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Brian Lovely
>> Sent: Wednesday, August 24, 2016 12:39 PM
>> To: = EMAIL ADDRESS REMOVED =
>> Subject: [WebAIM] Fwd: Dynamic Form Input Rules
>>
>>
>> Sorry about the forward; this isn't sending from my work account
>>
>> Brian Lovely
>> = EMAIL ADDRESS REMOVED =
>>
>> Begin forwarded message:
>>
>>> From: "Lovely, Brian (CONT)" < = EMAIL ADDRESS REMOVED = >
>>> Date: August 24, 2016 at 1:37:15 PM EDT
>>> To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>>> Subject: FW: Dynamic Form Input Rules
>>>
>>>
>>>
>>> From: Lovely, Brian (CONT)
>>> Sent: Wednesday, August 24, 2016 8:56 AM
>>> To: 'WebAIM Discussion List'
>>> Subject: Dynamic Form Input Rules
>>>
>>> I would like someone who is a screen reader user to tell me what the
>>> ideal experience would be for this. Here is the current, less-than-ideal flow:
>>>
>>> When a form text input receives focus, the usual stuff is announced.
>>> So far, everything is fine. Once you start typing, though, a
>>> container appears below the input (after it in code order). The
>>> container holds a series of rules regarding the correct format for
>>> the input: At least a certain number of characters, no spaces, at
>>> least one numeral, there are four or five of these rules. Each rule
>>> is preceded by a graphic, either a red "X" or a green checkmark.
>>> Non-fulfilled rules have the "X", fulfilled rules the checkmark. When all rules are met the container disappears.
>>>
>>> I know this is problematic (for instance, the fulfilled/not-fulfilled
>>> state of each rule is not read out), but what would be the ideal way
>>> to communicate these kind of rules (for instance, for creating a user
>>> name or password)? Feel free to alter/remove the location of the
>>> container, the appearing/disappearing of the container, the graphic indicators, etc.
>>>
>>> <image001.png>
>>> Brian Lovely
>>> Digital Accessibility Team
>>> = EMAIL ADDRESS REMOVED =
>>>
>>>
>>>
>>> The information contained in this e-mail is confidential and/or
>>> proprietary to Capital One and/or its affiliates and may only be used
>>> solely in performance of work or services for Capital One. The
>>> information transmitted herewith is intended only for use by the
>>> individual or entity to which it is addressed. If the reader of this
>>> message is not the intended recipient, you are hereby notified that
>>> any review, retransmission, dissemination, distribution, copying or
>>> other use of, or taking of any action in reliance upon this
>>> information is strictly prohibited. If you have received this
>>> communication in error, please contact the sender and delete the material from your computer.
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
> The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
> > > >