Accessibility Issues with BoA Online Banking Interface [FWD]

note: this is a copy of a post to a member-only list, which does not
contain any member-confidential information, therefore, i have posted
it to www-archive so as to make it available in a public archive

----------
From: oedipus@hicom.net
Date: Tue, 31 Jan 2006 16:12 +0000
To: [eddress deleted]
Subject: Accessibility Issues with BoA Online Banking Interface [FWD]

dear ms. [name deleted] - thank you again for your assistance this 
afternoon.  i am placing the message i sent to mr. reeves 
and carbon-copied to accessiblebanking@bankofamerica.com in 
the body of this emessage - if any of the HTML/XHTML code 
contained herein is corrupted by the web mail interface i 
am emailing you from, please let me know, and i will resend 
the emessage as an attachment.

again, i cannot thank you enough for your patience, 
understanding, and responsiveness.  as i indicated during 
our conversation, i have been attempting to get these 
issues addressed since BoA bought out fleet bank, where i 
had an account by virtue of fleet having bought out my 
original banking institution, summit bank.  i truly 
appreciate the seriousness and gravity with which you are 
treating this matter, and "look" forward to working with 
BoA to address slash redress the issues outlined below, 
which, as i stated during our conversation, address the 
most egregious accessibility issues with BoA's web 
interface, and have included specific programmatic 
suggestions where possible, including reformatted forms 
and tables.  however, since once one is logged into BoA's 
online banking interface, the user's ability to obtain the 
source code underlying the web document (the web document's 
DNA, so to speak) is blocked, so i could only provide 
specific examples of accessible code where i could obtain 
the document source.  however, i did attempt to address the 
design and implementation decisions that are at the root of 
the inaccessibility of BoA's online interface, such as:

* the lack of separation between style and content;

* the invalidity of the code used to construct the pages 
  (the first step towards accessible web documents is to 
  ensure that the code used to construct them validates 
  against a recognized and peer-reviewed standard);

* the lack of and/or misuse of structural and contextual 
  markup which would inestimably assist ALL users;

* the use of invalid form controls which make it 
  difficult, if not impossible to ascertain what 
  submission links belong to what form controls;

* the use of ambiguous hyperlink text;

as well as other related issues which i hope to discuss in 
greater detail with whomever is responsible for the oversight 
and implementation of BoA's online interface.

so, while the following is not a comprehensive list of issues 
which need to be addressed, it does address the most egregious 
accessibility problems with the BoA web site, and was (and is) 
intended to open a dialog with those responsible for BoA's web 
interface on both a policy level, as well as a very technical 
level.

thank you again for your attention to this very serious matter,
gregory j. rosmaita
phone: 1 973 746 1192
email: oedipus@hicom.net AND unagi69@concentric.net

--- FORWARDED EMESSAGE ---
From: oedipus@hicom.net
  To: [Name and Eddress Deleted]
  CC: accessiblebanking@bankofamerica.com
Date: Thu, 26 Jan 2006 20:02 +0000 
Subj: Accessibility Issues with BoA Online Banking Interface

dear mr. [name deleted]:

i am emailing you because i was given your email address as 
a contact for addressing accessibility problems with the 
bank of america site.  if you are not the correct person to 
whom to address such issues, please forward this emessage 
to whomever is charged with overseeing the accessibility of 
the BoA web site.  if it does fall within your purview, 
please feel free to circulate this emessage to whatever 
colleagues you deem appropriate and/or necessary.

as a blind user, it is essential that -- in order to retain 
my autonomy over my finances, not to mention my privacy -- i 
have complete and unfettered access to your web-based 
interface.  while i commend BoA's stated commitment to 
accessibility, and i most certainly appreciate the roll-out 
of accessible ATMs at BoA branches, the BoA web site presents 
a host of insurmountable problems for the any user who isn't 
fortunate enough to have use of his or her eyes, the ability 
to correctly process visually presented information in 
accordance with the intentions of BoA's web designers, and the 
capacity or capability to point-and-shoot one's way through a 
web site.

despite BoA's claims of complying with the W3C's guidelines,
such as that found on:

http://www.bankofamerica.com/accessiblebanking/index.cfm?
template=ab_web_access

the site most definitely does NOT comply with any of the W3C's 
guidelines, nor does the source code used on the site validate; 
i happen to know a bit about both accessibility and validity, 
having been an "invited expert" to the W3C since 1997.

if the BoA site did comply with any of the W3C guidelines, or 
any of the other universal design guidelines which have been 
promulgated in the last decade, this emessage would be 
uneccesary.  however, my experience as a blind individual, a 
BoA account holder, and an "invited expert" to the W3C 
compel me to make yet another attempt to provide BoA with 
the detailed feedback necessary for it to actually live up to 
its self-proclaimed commitment to:

quote
continually enhancing our Web environment to increase 
accessibility and usability for all of our customers. These 
enhancements are based on universal design and priorities one 
and two of the World Wide Web Consortium (W3C).
unquote



ISSUE 1 - BillPay Problems:

1. selecting the "Go to Add Payee" hyperlink does NOT take 
one to the form whereby one adds a Payee, but to the 
following string of text:

To add a new payee, click _Show_.

with the word demarcated with underscores, "show", as the 
actual hyperlink.  this is NOT sufficient from an 
accessibility point of view, nor is it logical from a 
design standpoint.  first, why is the hyperlink text not:

"add a new payee"

which is unambiguous, rather than "show" which is not only 
ambiguous, but which is used twice on the same page as 
hyperlink text; despite the use of identical hyperlink 
text on multiple links, each hyperlink leads to a different 
destination.  it is essential, not only from an accessibility 
standpoint, but for general useability's sake, to ensure that 
identical hyperlink text points to identical targets.  not 
only should hyperlink text explicitly indicate the nature and 
identity of the target of the hyperlink, thereby eliminating 
such ambiguous hyperlink text as "here", "this", "click here", 
"click this", or "show" from consideration when designing and 
implementing a site; especially a site where accuracy and 
precision are essential to the user.

second, why does not the "Go to Add New Payee" link actually 
take one to the "Add New Payee" interface?  it is not an 
unreasonable expectation that a link which explicitly states 
that it will enable the user to "Add a New Payee" actually 
takes the user to an interface that allows him or her to do 
precisely that -- add a new payee; rather than taking the 
user who wishes to add a new payee to a hidden form which 
will only be exposed if one can either (a) make sense of 
the ambiguous hyperlink text, (b) is willing to follow 
multiple links to locate the link one actually needs to 
activate, or (c) parse the document's source and scripting 
in order to ascertain which is the correct hyperlink and 
destination combination necessary to perform what was once, 
and should remain, a simple task: adding a payee. obviously, 
this constitutes an "undue burden" on the individual user, 
whereas ensuring that the BoA interface uses valid source 
code and conforms to the accessibility guidelines promulgated 
by the World Wide Web Consortium (W3C - consult 
http://www.w3.org/WAI/) is not only simple, but has the 
benefit of ensuring that the BoA site is useable by all 
BoA account holders, regarless of their situation, 
circumstances, or the technology they use to access 
information.  accessibility is but an aspect of useability; 
ensuring that the BoA site is accessible will also make the 
site itself easier for every account holder to use.


ISSUE 2 - Forms:

1. please use valid form controls and valid form labeling 
mechanisms (LABEL, LEGEND, FIELDSET, etc.) on ALL forms; 
there is, for example, no reason why the Accessible ATM 
locator, located at:
http://www.bankofamerica.com/accessiblebanking/
isn't encased in a FIELDSET, with "Find a Talking ATM" 
as the LEGEND defined for that FIELDSET; it would not 
only serve to separate this form from the "Search" form 
which also appears on the page, but would make it clear 
to the blind user that the LABELed fields "Street", 
"City", "State" and "Zip Code" pertain to finding an 
accessible ATM.  at the very least, rather than using 
a null value for the "summary" attribute of the TABLE 
that contains the "Find a Talking ATM" form, you should 
use this attribute for its intended purpose: to provide 
contextual information about the contents of the table 
it summarizes -- in this case summary should equal 
"Find a Talking ATM" in order to be in compliance not 
simply with the W3C's guidelines for web content 
accessibility, but, to be compliant with HTML 4x and 
XHTML 1x,

quote
summary = text [CS] 
This attribute provides a summary of the table's purpose and structure 
for user agents rendering to non-visual media such as speech and Braille. 
unquote
[source: 
http://www.w3.org/TR/html401/STRUCT/tables.html#adef-summary

2. please use form controls to submit or cancel submission 
of the data entered into a form, rather than the 
javascripted links that currently substitute for form 
controls on the BoA site.  why?

2a) using standard form controls for the submission or 
resetting of form data allows a user to differentiate between 
multiple forms which appear on a single page -- my screen 
reader allows me to generate a list of form controls, but 
without including the submission slash clear form controls 
within the form as form controls, it is impossible to 
easily discern (without recourse to document source) where 
one form ends and another begins.

2b) substituting hyperlinks for form controls adds to the 
identical hyperlink problem which is rampant on the BoA site 
-- how do i know which "Go" or "Cancel" link is associated 
with which form if there are multiple "Go" links, each 
associated with a different form, on a single page?

2c) you should NOT use TABLEs to visually slash graphically 
slash spatially format pages, using invalid code, empty 
columns and rows, and spacer images; TABLEs are a visual 
construct that only have meaning inasmuch as the user can 
discern the relationship between disparate pieces of data 
and their relationship between an item of data and the 
labelling/contextual information associated with that item 
of data on the X and Y axis, which is why TABLE-ized 
information MUST use the programmatic features built into 
HTML since version 4.0 (and which are built-into XHTML), 
such as the "summary" attribute (to describe the TABLE); 
the THEAD (Table Header), TFOOT (Table Footer) and TBODY 
(Table body) elements; if the use of TABLEs for formatting 
is deemed necessary by BoA, then there MUST be a strict 
separation between TABLEs that contain data (whether 
numeric or textual) and those that control formatting, 
rather than the sloppy mixing and matching of TABLEs that 
currently characterizes the BoA web site. (consult the 
next item for more detailed information)

2d) you can also demarcate the start and end of a FORM 
encased in a TABLE (as are almost all of the forms i've 
encountered at the BoA web site) by using the THEAD and 
TFOOT elements to indicate the start and end of a 
TABLE-ized FORM.  for example:

<TABLE border="0" cellspacing="0" cellpadding="0" width="187" 
  summary="Use this four field form to find the Talking ATM closest to 
you.">

<THEAD>
<TR><td style="display:none;">Find a Talking ATM</td></TR>
</THEAD>

<TFOOT>
<TR><td style="display:none;">End of Find a Talking ATM form</td></TR>
</TFOOT>

<TBODY>
<!-- insert rest of table-ized form here, keeping the pseudo-title an H2 -
->

</TBODY>
</TABLE>

Note that the use of the "summary" attribute should be universally 
applied to every TABLE on the BoA site that is used to visually 
demarcate a block of text or controls that are related, and are 
essential to a full understanding of the contents of a document 
which is formatted using the TABLE element for stylistic reasons, 
and not limited merely to TABLEs that contain FORMs.  an example 
of this can also be found on 
http://www.bankofamerica.com/accessiblebanking/

<!-- begin extant document source -->
<table border="0" cellspacing="0" cellpadding="0" width="187" summary="">
<!-- end extant document source -->

<!-- begin corrected document source -->
<table border="0" cellspacing="0" cellpadding="0" width="187" 
   summary="Layout Table Containing Links to Accessible Banking 
Information">
<thead><tr>Accessible Banking Information Center"></tr></thead>
<tfoot><tr>End of Accessible Banking Information Center</tr></tfoot>
<tbody>
<!-- extant document source would go here -->
</tbody>
</table>
<!-- end extant document source -->

why is the use of the "summary" attribute so important?  because 
aside from providing contextual information about the nature, 
function, intent, and size of a form, it is recognized by the 
major screen reading products on the market, whereas THEAD and 
TFOOT have been spottily implemented by browser manufacturers, 
which is why i suggested the use of the CSS value 
"display: none;" so that the information will be passed along 
aurally to those experiencing the page aurally, whilst it will 
be invisible to those experiencing the page visually.

for fully functional examples of a BoA form, reformatted for 
accessibility, please consult the following:

index: http://www.hicom.net/~oedipus/temp/BoA/atm_locator_gjr.html
option 1: http://www.hicom.net/~oedipus/temp/BoA/atm_locator1.html
option 2: http://www.hicom.net/~oedipus/temp/BoA/atm_locator2.html

(note: of the 2 options, i would strongly recommend the second,
however, i accomodated the tablization of the FIELDSET form in 
option 1, in keeping with the current design structure of the BoA 
site, which uses TABLEs for layout, rather than controlling layout 
through the use of the DIV element in HTML/XHTML and the use of 
CSS to control placement, flow, etc. - i would strongly encourage 
you to consult sites such as the W3C's site [http://www.w3.org], 
the Web Accessibility Initiative's sub-site [http://www.w3.org/WAI/], 
and the site of the American Foundation for the Blind 
[http://www.afb.org/] for "real-life" examples of the use of 
valid and accessible markup)


3) this is not an accessibility problem, per se, but why is 
there a limit on the number of characters that one can enter 
into the "Company Name" text-entry field?  how can one have 
an electronic check cut for a company whose full name 
doesn't fit in the "Company Name" field?  the check MUST 
have the full name of the company on it to be valid, but 
the hard cap on the number of characters allowed in the 
text entry field for "Company Name" often precludes this.


ISSUE 3 - Timeout:

when one is blind or visually impaired, there is no 
overall, all-encompassing, gestalt view of a web document; 
rather, the blind or low vision user experiences the 
document serially and linearly.  this is one of the reasons 
why unambiguous hyperlink text is so important, and why it 
is so important that when identical hyperlink text is used 
each of the links points to the same target.  the aural 
and highly-magnified experience of a site such as BoA's, 
therefore, is extremely time-consuming, as the site's 
designers have attempted to put as much functionality into 
each page as possible.  moreover, simply listening to a 
page, obtaining a list of links on a page, obtaining a list 
of forms on a page and ascertaining the individual form 
elements that comprise each form does not, from a browser's 
or server's programmatic point-of-view constitute activity, 
leading to premature time-outs.  while the site is set to 
generate an operating system warning that the session is 
about to time out, such a warning may not be announced by 
a users' screen reader, or caught by a user's screen 
magnification program.  worse, if the user is switching 
between a browser displaying the BoA web site and another 
program, such as NotePad, where the user keeps his or her 
banking information, or which a user is using to make a 
text image of a statement or an account's recent activity, 
such pop-up warnings can be inadvertantly cleared by a 
keystroke intended for the application being used for 
note-taking, or the warning (which in my personal 
experience does NOT come to the forefront of the desktop) 
may be imperceptable to the user until he or she attempts 
to return to the browser instance in which the user's BoA 
information is displayed, forcing the user not only to 
start whatever task he or she had begun over again from 
the beginning, but to re-login to the BoA system.  even 
when the warning is generated and perceived by someone 
like myself who is operating in an eyes-free environment, 
due to the association of a system sound with the system 
alert dialogs, one cannot always get to the alert in time 
to stop the server from logging one out.

i fully understand WHY BoA times-out sessions after a 
specified period of inactivity, and i appreciate that it 
does so from a security point of view, but as a blind 
user, i find that the annoyance of having to relogin and 
restart whatever task i had begun from the beginning - 
on occasion multiple times - far outweighs my appreciation 
for this particular security measure.  is there no way to 
allow a user to choose a longer timeout period?  the onus 
would be squarely placed on the user whether or not to 
extend (or shorten) the timeout period, and the 
ramifications of the user's action in this regard would 
be his or her responsibility slash liability.

if offering user-control over session time-outs is deemed 
impractible or unadvisable by BoA, could not some 
accomodation be made for those users who are known to 
BoA, or who identify themselves to BoA, as having special 
technological needs (such as the use of a screen reader, 
a screen magnification program, speech input, an eyeball-
tracking mouse, an on-screen keyboard, etc.) to extend 
the time out period?  this isn't as impractical as it may 
sound on first reading, as BoA is forcing its online users 
to use the SiteKey system, for which an ambiguous promise 
of accessibility for those who cannot process visual 
information (a group that includes not only the blind and 
visually impaired, but those with certain types of 
cognative impairments) has been made.  surely, if there 
is a way for me to verify my SiteKey non-visually, there 
should be a way for the BoA server to programmatically 
note that i need to tailor the server's default timeout 
period.

whilst i will address specific problems i have encountered 
with the SiteKey mechanism so far in a separate section, it 
should be noted that since my session timed out whilst i was 
attempting to set up my SiteKey, i have not been able to 
log back into BoA's online banking services, as i am 
prompted for my "online ID", which i never had the chance to 
create, since i was carefully reviewing the SiteKey 
instructions, and attempting to use the SiteKey help to 
ascertain precisely how the SiteKey mechanism -- not to 
mention the SiteKey registration interface -- is supposed to 
function when one cannot perceive the visual SiteKey.  as a 
result, i cannot currently log back into the BoA site, for 
whilst the "where do i enter my passcode" hyperlink states:

quote
NOTE: If you have not yet created your personalized SiteKey, 
you will be prompted to do so before you can sign in to 
Online Banking.
unquote
[source: 
http://www.bankofamerica.com/privacy/sitekey/EnterPasscodePopup.cfm]

the BoA site has NOT prompted me to create a personalized 
SiteKey since i was timed out, despite having shut down 
my browser, and even rebooting my computer.  which leads 
me to the final issue i wish to address in this emessage:


ISSUE 4 - SiteKey Sign-Up Problems:

first of all, why is BoA using a turing-type test as a 
security measure, rather than using signed certificates, 
and other non-intrusive digital security measures?  

second, in attempting to use the BoA site, i was confronted 
by the SiteKey introductory page, which raised the following 
issues:

1. there is insufficient information (aside from a brief 
mention in the introductory text that an accomodation has 
been made for those who cannot see images) for a blind 
user to:

a) choose an image (the ALT text assigned to each image is 
archival in nature, not contextual, and does NOT provide 
any REAL information about the contents of the image)

b) entitle the image (if i don't know what the image is, 
how can i title it?)

2. when my session timed out, i could not return to the 
SiteKey Sign-Up interface to complete my attempts at 
obtaining a SiteKey and testing its accessibility, as 
outlined in the last paragraph of the preceding issue 
statement;  why did my sesssion time out?  because, as 
i indicated, i was attempting to be cautious, as it 
behooves anyone when handling one's business affairs, 
using whatever assistance was provided to find out as 
much as i could about SiteKey, as well as attempting to 
keep a log of the problems with the interface that i 
experienced whilst attempting to obtain a SiteKey.

please address these issues (a) seriously, 
(b) comprehensively, and (c) immediately, as there is 
nothing more important to an individual than his or her 
autonomy, and nothing more detrimental to that autonomy 
than losing direct control over and knowledge of one's 
finances, which is precisely the result of the 
accessibility problems at the BoA site for those of us 
unable to process visual information.

sincerely, gregory j. rosmaita
phone: 1 973 746 1192
email: oedipus@hicom.net

BoA Reformat Options and Related References
(note that the "o" in "BoA" is lowercase):
  http://www.hicom.net/~oedipus/temp/BoA/atm_locator_gjr.html

DateStamp for the construction of this emessage and the 
accompanying examples:
	1/22/2006 [10:40AM to 6:29PM]
	1/23/2006 [12:33PM to 4:07PM]

------------------------------------------------------------------
ACCOUNTABILITY, n.  The mother of caution.
                          Ambrose Bierce, _The Devil's Dictionary_
------------------------------------------------------------------
Gregory J. Rosmaita:                             oedipus@hicom.net
Camera Obscura:           http://www.hicom.net/~oedipus/index.html
VICUG NYC:          http://www.hicom.net/~oedipus/vicug/index.html
Read 'Em & Speak:   http://www.hicom.net/~oedipus/books/index.html
UBATS - United Blind Advocates for Talking Signs: http://ubats.org
------------------------------------------------------------------

Originally received on Wednesday, 15 November 2006 21:36:50 GMT

Received on Sunday, 5 August 2007 00:04:39 UTC