Accessibility test-character counter

[nrustand92]

@shawnthompson @masterbee As discussed in #952 would you guys be able to do an accessibility test for a character counter feature for Canada.ca feedback form, perhaps in time for R 1.6? Thanks a lot!

[nrustand92]

Would you guys be able to give a time estimate? My boss @cdennis2 would like to be kept in the loop, thanks!

[thomasgohard]

The Paciello Group found that screen reader support for ARIA live regions was "mixed at best" just a year ago: http://www.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/.

I did some testing the other day using Chrome, Firefox, and Safari with VoiceOver (didn't have access to a non-OS X system at the time). For VoiceOver at least, support hasn't improved in the last year. I could get it to read the contents of the live region only if I set it to assertive, and, if I remember correctly, only in Safari. Otherwise, nada.

[nschonni]

I saw went to http://www.csun.edu/cod/conference/2015/sessions/index.php/public/presentations/view/165 but I don't think they have been allowed to release the content. Mainly comes down to that you need to do alot of handholding using timeouts to get iOS to even closely play nice.

[shawnthompson]

@masterbee found this: http://webstandardssherpa.com/reviews/improving-the-tweet-box/

[LaurentGoderre]

Aria-live sounds like a bad idea...each keystroke would read the key then the number of characters left.

[pjackson28]

It can be beneficial, but only if done correctly. That is where it is important to choose the correct settings and if necessary limit updates. That is what we did with form validation to ensure the aria-live region didn't do more harm than good (limited updates to actual changes versus each message refresh). So for instance the status role would be more appropriate for something like this since aria-live is set to polite by default. If polite is not good enough, then maybe have a hidden aria-live region that is only updated with the current tally after a period of inactivity from the user (e.g., a couple of seconds). Of course it would require user testing to ensure that it is actually a benefit to the user.

Even if aria-live support is not universally good, the benefits it provides to those who do have support likely warrants its inclusion. Why force a lesser experience on those who do have proper support? So it can be provided as an enhancement but should not be the only way of obtaining the information. So in this case, if the screen reader user does not have good aria-live support, they can always go to the character count area to get the latest tally or to submit anyway and get an error message if the answer is too long.

[thomasgohard]

@pjackson28 I agree, for those who do support it, let's include it (status="role" is also what I figured would be most appropriate). I was just mentioning that it may not be the case for most. So we should look at alternatives for those who do not have the support.

In the case of the character count, it could be as simple as specifying the maximum character count in the label and validating the input to ensure it does not exceed the maximum character count. That's what I'm testing next.

[hsrudnicki]

@nrustand92 @LaurentGoderre @masterbee @thomasgohard @shawnthompson
@pjackson28 @nschonni : Can we tackle/finalize the issue in order to close it?
Based on your discussion:

• First suggestion: as a website chock full of rich, JavaScript-driven interactions, ARIA Live Regions for notifying users seems like a natural choice but ARIA live region isn’t always desirable even with setting to assertive
• Second suggestion: the most widely supported combination is to use aria-live with role=”status” to create the ARIA live region, where elements with the role status have an implicit aria-live value of polite, and an implicit aria-atomic value of true;
  if aria-live = ”assertive” then two browser/screen reader combinations remain unsupportive that are NVDA and Window Eyes in Internet Explorer, but are the two very crucial?
• As simplest, for basic accessibility, "label elements are incredibly useful in that they are read by assistive technologies when a form control is focused and clicking on them will focus (or select) the associated form control", so it's important to explicitly associate label elements with form controls using the for attribute with referenced an id of the form control - For example: Use of jquery, for example jquery character countdown in textarea as a "counter", where the remaining character info is stored

[hsrudnicki]

Your solution to this issue can help in fixing the following related issue(s):
Character limit for Canada.ca feedback form: #952 [ with reference to Feedback form comment box-character limit Feedback form comment box-character limit https://github.com/wet-boew/wet-boew/issues/6534 ]

[nrustand92]

@hsrudnicki I agree
On May 5, 2015 2:55 PM, "hsrudnicki" notifications@github.com wrote:

Your solution to this issue can help in fixing the following related
issue(s):
Character limit for Canada.ca feedback form: #952
#952 [ with reference to
Feedback form comment box-character limit Feedback form comment
box-character limit wet-boew/wet-boew#6534
https://github.com/wet-boew/wet-boew/issues/6534 ]

—
Reply to this email directly or view it on GitHub
#968 (comment).

[hsrudnicki]

wet-boew/wet-boew#471 - Automated Accessibility Checking

[hsrudnicki]

wet-boew/wet-boew#552 - Mobile testing checklist

[hsrudnicki]

wet-boew/wet-boew#6070 - Components in need of test suites

[hsrudnicki]

@shawnthompson and others: Label this issue as "Going Stale"? Either way, please update this issue's status, whether this issue, also referenced with the others, can be closed as resolved/closed or if otherwise? Thank you

[hsrudnicki]

Please update this issue's status whether this can be closed or otherwise? Thank you

[dravas-nat]

@nrustand92 @LaurentGoderre @masterbee @thomasgohard @shawnthompson
@pjackson28 @nschonni :
here at CRA we are in need for such functionality in several of our web applications.
is there anyone working on this request? what's the status?
it looks like a solution was found for this request in Issue #6534:
@LaurentGoderre were you or someone else able to implement this feature on a working example?
see Issue : wet-boew/wet-boew#6534

thank you in advance.
nathalie

[nrustand92]

Not sure who's working on this, but I am still interested in getting the
counter developed
On Aug 30, 2016 5:31 PM, "Nathalie" notifications@github.com wrote:

@nrustand92 https://github.com/nrustand92 @LaurentGoderre
https://github.com/LaurentGoderre @masterbee
https://github.com/masterbee @thomasgohard
https://github.com/thomasgohard @shawnthompson
https://github.com/shawnthompson
@pjackson28 https://github.com/pjackson28 @nschonni
https://github.com/nschonni :
here at CRA we are in need for such functionality in several of our web
applications.
is there anyone working on this request? what's the status?
it looks like a solution was found for this request in Issue #6534:
@LaurentGoderre https://github.com/LaurentGoderre were you or someone
else able to implement this feature on a working example?
see Issue : wet-boew/wet-boew#6534
wet-boew/wet-boew#6534

thank you in advance.
nathalie

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#968 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFrGloVORWmLPZD98hvhYpWe_Wzp-JPwks5qlKEdgaJpZM4D7-W4
.

[LaurentGoderre]

No, I never got to work on this.

[shawnthompson]

Here's a good version of an accessible character counter.

Characters Remaining Counter

cc/ @andrewnordlund

[jasonday]

Here's an approach I came up with: https://codepen.io/jasonday/pen/xxEqBoQ
It uses a debounce function to throttle the keystrokes and uses an aria-live="polite" to announce the characters remaining. It works well in my testing across FF/NVDA, iOS/Voiceover/, Chrome/JAWS.

I realize this ticket is old, but maybe it will get picked up again.