screen readers and bank account numbers
Hi folks,
Any ideas on the best way to mark up bank account numbers so that they are read out as individual digits by screen readers?
Caveat is that they have to appear without spaces on GUI browser.
Thanks in advance.
Phil Smears
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share: 
I know it's painful but how about:
| Code: |
| <p class="bankno">1<span> </span>2<span> </span>...</p> |
| Code: |
| p.bankno span {width:1px} |
Or a similar varient.
Cumbersome I know, but it should work.
mike 2k:)2
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
i'd say write it down as normal. it's up to the assistive technology (and/or the user) to switch to individual character reading mode. but that's my hardline opinion 
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
I'm with redux. This comes down to displaying information in a clear and comprehendable language, which the standard bank account number is - it's well known banking 'terminology'. Modifying that in a structural way could be dangerous. mike's solution will look OK, but if you copy and paste... 
A user on a banking site knows they're on a banking site - after all, they asked to be there. Therefore they will understand that the section "Card number: 9288 0000 0000 0000" is indeed a card/account/whatever number, and not the sum of money they currently have deposited.
Unless you use badly structured tables.
Kajun
Share:
| Kajun wrote: |
|
A user on a banking site knows they're on a banking site - after all, they asked to be there. Therefore they will understand that the section "Card number: 9288 0000 0000 0000" is indeed a card/account/whatever number, and not the sum of money they currently have deposited. Unless you use badly structured tables. |
Thanks for the reply but you seem to be missing the point. Yes, the visitor to the site knows it's an account number but if you hear for example "account number one million two thousand and thirty six" coming out of the screen reader it takes a bit of mental juggling to work out that the account number is 1002036. This essentially is the problem.
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share:
| philsmears wrote: |
|
Thanks for the reply but you seem to be missing the point. Yes, the visitor to the site knows it's an account number but if you hear for example "account number one million two thousand and thirty six" coming out of the screen reader it takes a bit of mental juggling to work out that the account number is 1002036. This essentially is the problem. |
no, the user of the screenreader will know that it's a bank number when it start to say "one million..." and switch his/her screenreader to read a character at a time (in the case of JAWS, it's INSERT + NUM PAD 5 for instance - that spells the current word; i can't test it from home, but it should work just as well with numbers). the onus is also on the user.
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
| redux wrote: |
|
no, the user of the screenreader will know that it's a bank number when it start to say "one million..." and switch his/her screenreader to read a character at a time (in the case of JAWS, it's INSERT + NUM PAD 5 for instance - that spells the current word; i can't test it from home, but it should work just as well with numbers). the onus is also on the user. |
Home page reader wasn't doing it but maybe I can get it to do it. I'll check it out again.
Cheers
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share:
Even pwWebSpeak has a function for spelling things out one character at a time.
If screen readers honoured aural style sheets, this would be easy.
Tommy has left the building
Share:
| philsmears wrote: |
|
Home page reader wasn't doing it but maybe I can get it to do it. I'll check it out again. |
HPR is not a serious tool anymore, as it's quite dated and only has limited support for the majority of accessibility features of HTML. it offers a limited, nay non-existent set of features that would be truly indispensible for a regular user. as it's only a talking browser, it's not used by blind users. actually, don't think anybody is seriously using it (except for web developers wanting a cheap and cheerful way to test their pages).
Patrick H. Lauke / webmaster / University of Salford
co-lead: WaSP Accesibility Task Force
take it to the streets ... WaSP Street Team
personal: splintered | photographia | redux
co-author: Web Accessibility - Web Standards and Regulatory Compliance
Share:
Agreed that users will almost certainly know what they need to do to get the numbers to sound right -- especially if they are doing on line banking regularly.
Also...
| redux wrote: |
| HPR is not a serious tool anymore, as it's quite dated and only has limited support for the majority of accessibility features of HTML. |
I agree with redux that HPR is of limited use... One of the only things we value in it is for use in demonstrations -- for a long time, HomePage Reader was the only software of its kind that allowed for/supported language changes on the fly (via the lang attribute)
The latest version of JAWS supports on the fly language/dictionary switching (and the next version of WindowEyes could very well follow suit). However, we still keep HPR running to demonstrate the concept of language switching, and maintain JAWS 4.51 running for demos. Eventually when we start using JAWS 5 for demos, I'm guessing we won't get near HPR...
Share:
| philsmears wrote: |
| Yes, the visitor to the site knows it's an account number but if you hear for example "account number one million two thousand and thirty six" coming out of the screen reader it takes a bit of mental juggling to work out that the account number is 1002036. This essentially is the problem. |
As redux says, I don't think we need to pamper the user here. Even if the user is confused the first time by hearing 1 million etc., you've made it quite clear that it is an account number, by prefixing it with "account number". Even if it was a web site where the meaning/purpose of the number itself was completely ambiguous, the label provides the information that is lacking. Nothing more needs to be done. Using markup to force user agents into behaving in particular modes means you're making too many assumptions about the user and their assistive technologies; one could argue that trying to make HTML spell out things is attempting to make it a form of assistive technology itself, which, while laudable, can be conflicting.
Kajun
Share:
| Kajun wrote: |
|
Using markup to force user agents into behaving in particular modes means you're making too many assumptions about the user and their assistive technologies; one could argue that trying to make HTML spell out things is attempting to make it a form of assistive technology itself, which, while laudable, can be conflicting. |
No, playing around with the HTML wouldn't be the way.
In an ideal world we would be able to give the number a class and an aural style sheet would set it to character reading mode. Sigh.
The account number in question was part of a longish paragraph and when I switched to character reading mode so that the number was read out correctly I had to go back to the beginning of the paragraph and then wait until I got to the number again - a bit of a chore - unless there's a quicker way of doing it in Home Page Reader.
Anyway, thanks for the feedback.
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share: