Accessibility of UNB’s Web-based Services for Students with Visual Disabilities CS4983

Accessibility of UNB’s Web-based Services for Students with Visual Disabilities CS4983
UNB Faculty of Computer Science
Accessibility of UNB’s Web-based Services
for Students with Visual Disabilities
CS4983
I warrant that this is my own work
February 27th, 2003
Christa Welton
Executive Summary
The World Wide Web has brought knowledge and convenience to the lives of many.
However, users with visual disabilities are at a great disadvantage on the World Wide Web as
many websites are impossible for these users to navigate. There are many easy steps that can be
taken in the development stage that can ensure that websites are accessible to disabled users.
There are ethical and legal reasons why all websites must be equally accessible to all users.
The University of New Brunswick, like many other universities, offers services to its
students through its website. This paper examines the accessibility of UNB Student e-Services
and WebCT for students with visual disabilities. This is done by using guidelines for the
accessibility of web pages set in place by the World Wide Web Consortium and the steps for
accessibility evaluation of websites provided by the Web Accessibility Initiative. These steps
include manually checking web pages for accessibility and using automated tools. The automated
tools used in this study were A-Prompt, which is available from the University of Toronto, and
Bobby, which is available from CAST. It was also studied how well the pages tested complied
with the guidelines for accessibility set in place by the UNB Web Team.
This study found that both UNB Student e-Services and WebCT did not entirely comply
with the guidelines set in place by W3C or the UNB Web Team. There are some simple changes
that must be made in both of these websites to ensure that they will be accessible to students with
visual impairments. These changes include making sure all images have alternative text, using
proper HTML tags for data tables, using relative positioning and sizing, and giving frames
descriptive names.
I
Table of Contents
1.0 Introduction
2.0 Web Usability for Persons with Disabilities
3.0 Accessibility Guidelines
4.0 Accessibility Guidelines at UNB
5.0 Evaluating Accessibility
5.1 Pages Selected For Evaluation
5.2 Manual Accessibility Testing
5.2.1 Changing Browser Settings
5.2.1.1 Turn Off Images
5.2.1.2 Change Text to Largest
5.2.2 Navigation with Keyboard Only
5.3 Lynx
5.4 Tools for Evaluation of Accessibility
5.4.1 A-Prompt Testing of E-Services
5.4.2 Bobby Testing of e-Services
5.4.3 A-Prompt Testing of WebCT
5.4.4 Bobby Testing of WebCT
5.5 Evaluation of Results
6.0 Conclusions
7.0 Recommendations
Bibliography
Appendix A: A-Prompt Results for UNB Student e-Services
Appendix B: Bobby Results for UNB Student e-Services
Appendix C: A-Prompt Results for WebCT
1
1
3
5
6
6
7
8
8
9
10
11
13
15
16
17
18
18
20
21
23
II
1.0 Introduction
The World Wide Web has brought knowledge and convenience to the lives of many. The wealth
of information available online is empowering. However, some users may have difficulty receiving all of
the information available on the web. Just as buildings must be made accessible to persons with
disabilities, so must web sites. There are many easy steps that can be taken in the development stage that
can ensure that websites are accessible to disabled users. These steps can actually improve the usability
for all users, not just those with disabilities. So, it seems it would be very advantageous for businesses to
adopt these practices.
The University of New Brunswick, like many other universities, offers services to its students
through its website. This paper will examine the accessibility of these web services for students with
visual disabilities, whether they have visual impairments or are blind. This will be done by using
guidelines for the accessibility of web pages set in place by the World Wide Web Consortium and the
Web Accessibility Initiative. There are also utilities available online that will access the accessibility of
websites and offer recommendations to improve their accessibility. Two of these, Bobby and A-Prompt
will be used to evaluate the accessibility of the publicly available U.N.B. web pages. A-Prompt will also
be used to check the secure web pages.
2.0 Web Usability for Persons with Disabilities
According to a study conducted by Jakob Nielsen in 2001 on 104 users (including users who were
blind or who had visual impairments), “the Web’s current usability is about three times better for users
without disabilities than it is for users with disabilities” (8). This means that users who have vision
deficiencies or who are blind find the web three times harder to use and navigate than users without vision
deficiencies. This difference in usability is simply not acceptable, as every human being has a right to the
1
information available on the Internet. In recent years, many people have begun to study how the web can
be made more usable, or accessible, to users with disabilities.
How is accessibility different from usability? Usability consists of the learnability, memorability,
efficiency, satisfaction and low number of errors (12, p 26) of a web page. Accessibility is the “universal
usability” of a system or web page, which guarantees it is usable by the widest groups of users (17, p 32).
Put another way, “Web accessibility is the ability for a person using any user agent … to understand and
fully interact with a website’s content” (15, p 288). Therefore, accessibility does not just apply to disabled
users. It is also a concern to users in more remote areas of the world, users in lower economic classes and
users who speak different languages (15, p 288). Usability and accessibility are closely related. According
to Jacob Nielsen, “Usability and accessibility go hand in hand, and one without the other is not much use
in the real world”(11). But, the verification that a web site is accessible does not necessarily mean that it
is usable (8). Therefore, conducting an accessibility study does not give information about the usability of
the website tested. It only gives information as to the ability for many different groups of users to interact
successfully with that website.
There are many steps that can be taken in the development of websites that will ensure that a site
will be accessible to users with disabilities. Many of these options are cheap and easy to implement.
Ensuring that users have access to a text-only web page if the original web page cannot be made
accessible it is a good alternative for blind users who use screen readers. Accessibility should be
considered now, as it will become more important as the population continues to age. According to Gregg
Vanderheiden, “...functional limitations increase sharply as we age…(and)...a large percentage of these
limitations deal with vision, hearing and physical abilities”(17, p 33). It seems practical that accessibility
guidelines be in practise now to guarantee that the web will be accessible to all in the future as the
population ages. There is another reason why accessibility should be important to website developers. In
the U.S., there are three federally regulated laws that dictate that websites must be accessible to persons
with disabilities (15, pp 288-289). In Canada, the Canadian Charter of Right and Freedoms ensures that
all Canadians have access to information and services, regardless of disability (19).
2
3.0 Accessibility Guidelines
The World Wide Web Consortium (W3C) defined a set of guidelines in 1999 called the W3C
Content Accessibility Guidelines 1.0. These suggestions are not just to provide accessibility for web users
with visual impairments but also for users with other disabilities and users that are using older
technologies. There are ten guidelines that most affect the visually disabled. These will be taken into
consideration when evaluating the accessibility of UNB e-Services and WebCT websites.
The first guideline that affects the accessibility of websites for the visually disabled states that if
there is a video or audio clip as a component of the page content, then the information provided in this
clip should also be made available in some other form, such as a textual description (3, p 39). Also, if
there are images on the page, there should be descriptions provided for users that are not able to view
these images, either by use of the HTML alt tag to enter a short description or by using the longdesc tag
for longer description (3, pp 39-40). By using these tags, it will ensure that users who are using a text only
browser and screen reader will be able to gather “equivalent” information to users who can view the
images. These descriptions should be short and include only information necessary to the user, such as if
this image is a link to another page.
The second guideline recommended by W3C relates to users with colour vision deficiencies.
Information that is given to the user by use of colour alone will be missed, so there must be an alternative
way for the colour-blind user to get the same information that a person without colour vision deficiencies
would receive (3, p 40). For example, do not specify, “Please click on the red button.” Instead, give the
red button a name meaningful to its function like “Continue” and provide the instruction “Please press
continue.” The colours used on the page must also differ enough so that if viewed in black and white the
contrast would be great enough to distinguish between the two colours (3, p 40).
Blind users rely on screen readers to read the text on web pages to them. The third guideline
states that markup and style sheets must be used properly or the screen reader will not be able read the
information properly to the user (3, p 40). One example of improper use of markup is using a table for the
3
layout of the page. In a separate guideline, W3C recommends that tables should only be used for
presenting data and not for the layout of the page unless the table contents will make sense when read
linearly, as will happen when the page is read by a screen reader (3, p 42). Row and column headers must
be identified and a summary description of the table should also be provided (3, p 42). Not following
these guidelines will result in a large accessibility barrier to users relying on a screen reader because the
page simply will not make sense.
Another guideline that affects screen reader users concerns the ways of identifying the language
of a web page. Many screen readers are able to read numerous languages, but in order to change
languages they must have some sort of indication of the change or else they will try to pronounce those
foreign words as if they were in the first language of the page (3, p 41). Similar problems can also occur
with Braille devices, so it is crucial that the language changes of a page be specified through the markup
of the page or using HTML tags (3, p 42).
Blind users will not be using a mouse to interact with web pages, so a page that is designed for
mouse-only navigation will be inaccessible to these users. Providing keyboard shortcuts will make the
page more accessible as will making sure there is a logical tab order throughout the page (3, p 44). These
shortcuts will also be useful to users without vision deficiencies who are looking for faster ways to
navigate pages or for users who dislike using a mouse.
Many of these guidelines are common sense. For example, text that is moving or blinking may be
difficult or impossible to read for users with visual impairments and it is also impossible for screen
readers to interpret moving text (3, p 43). Other guidelines that appear obvious are making the layout of a
page as simple as possible and giving frames meaningful titles (3, p 46). However, some are not quite as
obvious. It might not seem like automatically refreshing pages, having pop-up windows, presenting text
in columns, or only having blank spaces for separation between different text links would be an
accessibility problem, but these can all create big problems for blind users (3, p 43-45).
4
According to W3C, “clear and consistent navigation mechanisms are important to people with
cognitive disabilities or blindness, and benefit all users”(3, p 47). They suggest that the text of links
should provide a clear indication of what type of information a link will provide a user if it is followed.
Other suggestions include providing a site map or table of contents, being consistent with the navigational
items of a page, grouping related links, allow different levels of searching, and distinguishing the
beginning of paragraphs, headers and lists with HTML tags (3, p 47). Following these guidelines will
make it easier for users, with and without visual impairments, to navigate web pages so that they will be
successful at finding the information that they are seeking.
4.0 Accessibility Guidelines at UNB
The UNB Web Development Team has set out guidelines for web pages that will be a part of the
UNB website. Their guidelines are a subset of the guidelines proposed by W3C. The guidelines that most
affect accessibility for the visually disabled include the recommendation that alt tags be used for all
images and to avoid using colour as the only indication of information (22). The Web Team has also
considered guidelines to make the presentation of data accessible to the visually disabled. When using
style sheets, they advise that the site be tested to see if they can be read without style sheets enabled and
their guidelines also caution that when tables are used strictly for layout to “make sure table structure is as
simple as possible” and to “make sure that the content is linearized so that it makes sense to speech
browsers” (22). The Web Team is also concerned that web developers at UNB test their websites using
simple methods to ensure their pages will be accessible. For instance, when using forms they suggest that
the page be tested in a text-based browser to make sure that it is still usable without graphics (22). Some
of their guidelines will help make UNB sites more accessible to everyone. The Web Team also cautions
that when using scripts to provide alternative functionality for when scripts are turned off by using the
“noscript” tag (22). During the evaluation of the Student e-Services and WebCT sites it will be examined
whether these guidelines have been met.
5
According to Megan Stewart, a Virtual Member of the UNB Web Team, the UNB Student eServices website was put together rather quickly, using existing web pages (16). Accessibility was not the
most important consideration at the time of creation of the site; therefore the Web Team is aware that
some pages may not be accessible (16). The testing in this report will uncover which of these pages is
inaccessible, which may be of use to the Web Team. There are plans to improve the accessibility of
Student e-Services in the near future (16).
Rik Hall, Manager of Instruction Technology at UNB, is in charge of WebCT. He offers courses
to instructors who wish to use WebCT in their classes. These courses do touch on web accessibility,
because instructors are responsible for making their own course pages accessible (5). This course is not a
requirement for instructors to use WebCT, so there may be many professors who are not aware of
accessibility (5). Since the course chosen for testing was created by Rik Hall it is possible that it is not
representative of all of the courses available on WebCT at UNB. However, since Mr. Hall does train some
of the professors who use WebCT, his course pages should be a good indication of what his students’
courses are like.
5.0 Evaluating Accessibility
Based on information from W3C’s Web Accessibility Initiative there are five steps that are used
in this report to evaluate accessibility. After selecting the pages, there are some manual checks and
automated checks that should be performed. The findings from the manual tests will be compared with
the findings from the automated tests to see which problems stand out. Findings from all of the tests will
be important to determine the overall accessibility of the pages selected.
5.1 Pages Selected For Evaluation
The first step suggested is to select “a representative sampling of different kinds of pages
from the Web site”(1). Following this advise, a sampling of pages from the UNB Student e-
6
Services and WebCT sites were chosen for testing. The e-Services pages included the Login
Page, the Main Page, and a selection of pages from each of these sections of e-Services:
Academic, Computing, E-Mail, Financial, Library Services and Personal. (Sections that were
excluded were Voting and Employees). From the Academic section the Apply for Undergraduate
Scholarships, View Class Timetable, View Exam Schedule and the View Marks/Transcript page
were selected. Also from the Academic section of e-Services were the Online Registration pages,
including the Introductory Page, Search for Classes, Search Results, View Schedule and the
Online Registration Main Page. Other pages selected included from the Computing section the
Change Pin page; from E-mail section the Check Mailbox Quota and WebMail Inbox pages; from
the Financial tab the Buy Print Credits and Fee Statement pages; from the Library Services tab
the Library Main Page as well as the Quest Search and Results; and from the Personal section the
Demographics Page was selected. The pages selected represent what is considered to be the most
used pages for a typical student.
From the WebCT website the Login Page was selected as well as the My WebCT Main
Page. The course pages that were tested were from the course created by Rik Hall on WebCT
entitled “WebCT- Learning It, Using It” which instructs on how to create course and quiz pages.
The quiz in this course was also among the pages tested.
5.2 Manual Accessibility Testing
In this section are the findings of testing UNB Student e-Services and WebCT using
manual tests. Tests performed included navigating the websites by keyboard only, and changing
the browser settings to turn off images and set the text size to the largest setting.
7
5.2.1 Changing Browser Settings
Both websites were testing by changing the browser settings. The browser used
was Internet Explorer 6.0. The two tests that were performed were to find out how the
page was perceived when images were turned off and also how well the page was
displayed when the text size was set to the largest setting, as it may be set for users with
visual impairments.
5.2.1.1 Turn Off Images
WAI suggests that, using a GUI browser, adjust the browser settings so
that images will not be displayed to verify if there is alternative text for images
and if the text provided gives the user accurate information (1). The purpose of
testing a website with the images turned off is to ensure that appropriate
information is available comparable to that which is provided when images are
turned on. Some blind users may use a graphic browser with their screen readers
and these users will miss any information conveyed in images unless the web
designer provides information by using the images’ alt tag. This test will examine
if appropriate alternative text information is provided to the user and if this “alt”
text improves the accessibility of this particular page.
There are many images that do not have alternative text provided, or the
text provided does not give an accurate enough description. One example of this
is the image map for the tabs in the top frame of the screen throughout the eServices pages, which contains the links to the various sections of e-Services.
This image map does have alt text. But since the tabs appear as one image the alt
text “My UNB e-Services” is lacking. Depending on where the mouse is moved
8
over parts of the missing image there are different links. This same image map
problem appears with the top frame of the Online Registration pages.
Some of the images that are missing descriptive alternative text are
important to the navigation of the page. For example, on the Online Registration
Instruction page, the link to continue at the bottom of the page appears as
“services.unb.ca:8080” without images displayed. Having the alt text of
“Continue” would make this more intuitive to use.
The WebCT pages tested had alt text provided for all images and this
text seemed to provide equivalent information to if there actually were images
displayed.
5.2.1.2 Change Text to Largest
WAI also suggests, when testing the accessibility of a page, to adjust the
browser so that the text size is set to the largest setting and observe whether the
text size changes show up on the page and if the page is still easy to use at this
larger text setting (1). Some users with minor to severe visual impairments may
set their browser text settings to large to make it easier to read, perhaps along
with the use of screen magnifiers. This is why this test is an important step in
accessibility testing.
The e-Services pages reflected the changes for the increase in font size.
The pages required more scrolling, but this is the price to pay for the increase in
text size. For the most part the pages retained their usability. However, upon
seeing how large the text was on the rest of the page, the tabs for the different eServices portals appeared very small in comparison, since these tabs are images
that do not enlarge in size.
9
One exception to reflecting the change in font size was the Main Page for
Library Services, which appeared the same as before changes were made.
However, the rest of the pages under Library Services did have enlarged text.
Also, the Online Registration pages, for the most part, do not reflect the enlarged
text setting, with the exception of the page that has instructions for using Online
Registration. With most of the pages in the Online Registration site, the text that
reflects the changes in the browser setting is not the text that contains the
information most important to the use of the page. For example, in the Search for
Classes page some of the text does indeed enlarge, but not the labels of the input
boxes. The fact that the input box labels do not enlarge may make it difficult for
those with problems reading small text.
WebCT retains its level of usability in larger text settings and all pages
reflect the changes in the browser settings. The WebCT main page requires
horizontal scrolling to view all of the contents of the page with the enlarged font
size. It seems that space is misused within this page since there is a lot of blank
area in the centre of the screen between the columns.
5.2.2 Navigation with Keyboard Only
W3C’s Web Accessibility Initiative also suggests negotiating the pages selected
with keyboard only to insure that the site is device independent (1). Testing a website
without the use of a mouse is very important in determining that the page is accessible to
users with severe visual impairments or to blind users. These users will not be using a
mouse to navigate web pages, but most likely they will be using a keyboard only, with
the use of a text-based or graphical browser and a screen reader.
10
It was found that all of the e-Services and WebCT pages had a natural tab order
that made it easy to navigate all parts of the pages. There were no instances of pages that
were not accessible without the use of a mouse. Therefore, both e-Services and WebCT
passed this test.
5.3 Lynx
The third step suggested by WAI is to use Lynx, a text only browser, to ensure that
“equivalent information (is) available … as is available through the GUI browser”(1) and to test
if “ the material (is) presented in a meaningful order if read serially”(1). The pages selected for
testing from the UNB Student e-Services website and the WebCT website were viewed through
the use of Lynx, a text-only browser. Text-only browsers are commonly used by the blind,
usually in combination with screen-reading software.
The most commonly found problem was images that did not have the appropriate alt text.
When these images are viewed in Lynx, the name of the graphic appears on the screen within
square brackets where the image is supposed to appear. The solution to this problem is to either
include alternative text (this is especially important if the image is a link) or to set the alt tag to
the empty string so that Lynx will ignore it.
Some of the places where images do not have alt text severely affect the usability of the
page. In the WebMail Inbox, for example, the image for the link to “Help” does not have any alt
text, but since all the other images on this page have alt text this may have been an oversight.
Also, in the On-Line Registration pages, the image map at the top of the page does not have alt
text. Selecting the link for this image map takes you to a page with the links for logout, login,
help and menu that appear when the graphics are displayed. Providing some descriptive alt text
would make it clearer that this image map contains links that may be important to a user.
11
Another problem found with the e-Services pages was that the e-Services pages for the
most part consist of three frames. These frames are what are presented as links when accessing
the e-Services pages in Lynx. The problem with this is that the name of the frames is not intuitive
enough for a user unfamiliar with the layout of the site to be able to navigate it. The names of the
frames are “tabs” for the top frame with the links to the different e-Services portals; “navigation”
for the side frame, which displays the different choices for each portal; and “content” for the main
portal. A slightly more descriptive name for each frame would improve accessibility.
A serious problem found when viewing e-Services pages with Lynx was the Academic
Services- View Class Timetable Page. This page was practically unreadable in Lynx. Each row of
the table is listed down the page, in effect displaying one row of the table per page. This is a big
problem as it is hard to identify which day of the week a class is on as you get further down the
table. There are some less serious problems with the table in the Exam Schedule Page where the
headings for the table are listed one on top of the other down the page before the rest of the table
is displayed so that the table headings are separated from the rest of the table. There were also
problems with the tables in the Search for Classes Results Page and the View Class Schedule
Page of On-line Registration with them being difficult to read as well because they took up
multiple lines or that the table headers cannot be viewed on the same page as some of the table
entries.
WebCT did well when tested in Lynx, but there were some problems. All images had alt
text so it was possible to understand what information was being conveyed. Although the
information in a graphics browser is displayed in two columns on the Login Page, it was readable
in one column spanning two pages in text-based mode. Tables and forms were also used in the
My WebCT Home Page, but they also translated well into the text-based browser so that it was
still easy to read the information. However, there were some problems with the fact that the page
uses JavaScript. Where the buttons are supposed to appear for “Go”, “Finish” and “Help” instead
12
[button] appears, but this is not a link. Therefore, it is impossible to navigate to the quiz page and
within the quiz page it is impossible to submit answers to the quiz.
5.4 Tools for Evaluation of Accessibility
The WAI suggests using two automatic utilities to test accessibility (1) so the fourth step
will involve using A-Prompt and Bobby to automatically check the accessibility of the web
pages. Bobby was created by CAST, an organization that strives to “expand opportunities for
people with disabilities through the innovative use of computer technology”(18). Bobby tests
pages to see if they comply with the Web Accessibility Initiative (WAI) of the W3C and can also
be set to check for compliance with the U.S. Government’s Section 508 Accessibility. Available
online, it can test one page at a time through its web-based version, or multiple pages through the
downloadable version. For this report the online version was used. Bobby identifies problems
within a page by breaking the errors down by priority. “Hats with wheelchairs indicate Priority 1
accessibility errors that are automatically detectable (18).” Question marks are placed on the parts
of the page that require manual checks to ensure that they follow guidelines (18). What makes
Bobby so easy to use is that it displays these symbols on the actual parts of the page that do not
comply with guidelines, so it is easy to check. All of the errors, Priority 1, 2, and 3 are also listed
at the bottom of the Bobby report so that the user can read through the list of errors and find out
how to fix each problem (18). There are also manual checks listed that suggest changes that
should be made because they are important for accessibility, some because they were triggered by
the design of the page and others that are included for every page tested.
A-Prompt, which stands for Accessibility Prompt, is a free utility created at the
University of Toronto with the Adaptive Technology Research Centre and the TRACE Center at
the University of Wisconsin working in collaboration (21). It tests a page for the W3C’s Web
Content Accessibility Guidelines and also allows the users to make corrections to the page (21).
They boast on the A-Prompt Project website, “A-Prompt will ensure that client Web sites are
13
accessible to the largest number of potential visitors – including those with disabilities”(21). APrompt identifies any problems that the page has and also includes the priority number that this
error falls under for W3C. The user can then “fix” the problem by going through the step-by-step
wizard type part of the program that guides the user to create a more accessible page. Not all of
the errors reported by A-Prompt may actually exist in the page tested. Some may be manual
checks that cannot be performed by computer and must be checked by a human. Others may
result because certain aspects about the design of a page trigger these warnings. Therefore, it is
very important to look through each of the errors to ensure whether or not they do exist for the
page tested. Going through and making the repairs using the wizard will show the user which
parts of the page triggered the error and what options are available to fix the problem. This wizard
makes this utility more attractive than Bobby. After running through the wizard it is possible to
save the changes made and have a more accessible page with little extra effort. In comparison,
Bobby does not help make the actual repairs, but simply advises the user of any errors and how
these errors should be remedied.
Both of these utilities use a system designed by W3C’s WAI that identify the priority of
each error. According to the Web Accessibility Guidelines 1.0 developed by the WAI, Priority 1
errors are errors that “must” be fixed immediately or else “one or more groups will find it
impossible to access information in the document” (3, p 38). These are the errors that will be
focused the most on in the report. Priority 2 errors are errors that “should” be resolved otherwise
“one or more groups will find it difficult to access information in the document” (3, p 38). These
errors are also important to focus on, as it is important for students to be able to access web
resources at UNB with minimal difficulty. Priority 3 errors are errors that “may” be addressed
because these errors could cause some users to “find it somewhat difficult to access information
in the document” (3, 39). Understanding the priority levels will make it easier to decide which
repairs must be made to ensure that UNB Websites are accessible to students with visual
disabilities.
14
One thing to note about utilities that measure the accessibility of websites is that they are
not foolproof. Accessibility tools can only automatically check for some accessibility problems
while the user has to manually check for things that can not be checked by a software utility, such
as if colours contrast (13, p 81). Another problem with these tools is that many tools may fail
pages that are indeed accessible (13, p 81). Therefore, it is important not to take the results of
these utilities as fact and to study them to ensure that they do indeed apply to the page tested.
5.4.1 A-Prompt Testing of E-Services
It is important to note that none of the pages passed A-Prompt testing. This does
not necessarily mean that there is something wrong with the pages. Most of these errors
require manual checking to ensure that they are not a problem for the accessibility of the
page. For a look at the more detailed results please see Appendix A.
With all of the UNB e-Services pages tested, many problems were reported for
every page. However, with manual checking, a good number of these problems were
found to be false alarms. The most common Priority 1 errors were images without alt
text, frames not having titles, scripts without a noscript section, tables that may require
markup, tables missing headers and images missing descriptive text. Manual Priority 1
checks that occurred for all pages were check if colour was used by itself to convey
information, check if language changes on the page needed to be indicated and also check
if the page required the use of styles or style sheets.
Priority 2 errors that were common for all of the e-Services pages included labels
missing for input boxes (for each of these instances, the input box did indeed have a
label), link text that may not be meaningful, tables that may not linearize properly, layout
table headers that are invalid, tables missing a caption, and pages without a DOCTYPE
statement. One Priority 2 error that occurred solely for the WebMail Inbox, which uses
15
auto-refresh, was that this feature must be removed. A new window requiring warning
error occurred on the first Online Registration Page because it opens up a new window
which may cause some confusion for blind users who are not aware that the active
window has changed.
The same Priority 3 errors occurred for most of the pages. These included colour
contrast low (which it did not seem to be for any of the pages this error occurred on),
input missing default text (which didn’t seem necessary any of the pages that this error
occurred), language of the page was not identified, table missing summary, data table
may require header abbreviations, multiple links missing skip-over, data table headers are
invalid, and image links also required backup text links for text-only browsers
5.4.2 Bobby Testing of e-Services
Since Bobby is a web-based utility, the secure pages could not be tested with this
utility because they were not available for the utility to access. However, the publicly
available pages were tested with Bobby and the observations are listed below. More
detailed findings can be found in Appendix B.
The only Priority 1 error that was reported was that there were images found that
did not have alternative text provided. It should be noted that with A-Prompt testing more
than one Priority 1 error was found for these pages. Also, with Bobby there were more
manual checks and suggested checks, but all of these passed.
Priority 2 checks included that relative sizing should be used instead of absolute,
a DOCTYPE statement should be used, make sure that event handlers are accessible
without a mouse, explicitly associate form controls and their labels with the label
statement, do not cause a page to redirect to a new URL, and do not use the same link
phrase more than once when the links point to different URLs.
16
Priority 3 recommendations were to provide a summary for tables, identify
language of the text, include default place-holding characters in edit boxes and text areas,
separate adjacent links with more than white space and that the client side image map
contains links that are not available elsewhere on the page, so this should be remedied.
There were also many manual checks that Bobby recommended be performed to
ensure that the pages are Bobby compliant. These included the recommendation to
consider grouping long lists of selections into a hierarchy; check if colours contrast; if
there are logical groupings of form controls use FIELDSET with LEGEND for each
group; avoid use of obsolete language features if possible; if a table is used for layout do
not use structure markup to achieve formatting effects; make sure that the user is aware
of pop-ups or changes in the active window; check if keyboard shortcuts would be
appropriate if not already available; and there were also some concerns over the use of a
table for the page layout. Notice that these user checks are also included in the A-Prompt
report, however in A-Prompt they are not given as manual checks.
5.4.3 A-Prompt Testing of WebCT
More detailed observations from testing WebCT with A-Prompt can be found in
Appendix C. Below are the most commonly listed problems.
Priority 1 failures included flicker in images, image maps missing alternative
text, not having a description or alternative text for images and some manual checks were
concerns over the use of colour to convey information (which it did not), not indicating
language changes on the page, script missing noscript section, checking whether the page
requires the use of style sheets, programmatic object may not be accessible,
programmatic object may require testing, and text equivalents require updating. Priority
2 concerns were that the headers on the page may require markup, link text may not be
17
meaningful, a script was found that is not keyboard accessible and the layout table may
not linearize properly. Priority 3 concerns included that the colour contrast was low, page
language was not identified, multiple links missing skip over and table missing summary.
5.4.4 Bobby Testing of WebCT
The WebCT Login Page was the only publicly available WebCT site, so it was
the only one that could be tested with Bobby. It had two Priority 1 errors: provide alt text
for all images and provide alt text for all image hot spots. Priority 2 errors included to use
relative instead of absolute positioning, and to use a DOCTYPE statement. Priority 3
errors were to provide a summary for all tables and to identify the language of the text.
Some manual checks included avoid use of obsolete language features whenever
possible. The rest of the user checks passed.
5.5 Evaluation of Results
The final step when evaluating accessibility is to analyse the results of all of the tests (1).
Examining the results of all of the manual and automatic tests, it was found that the UNB web
pages that were tested require some changes to be deemed accessible to visually disabled
students. On every page tested with the automated tools, there was the same Priority 1 error for
images not having alternative text. This was also backed up by the findings in the manual tests. It
is especially important that images that are links, or buttons, have alternative text provided so that
all users will enjoy the same functionality in these pages. Making these simple changes will make
most of the pages compliant with W3C regulations. However, some pages have more serious
problems.
Another Priority 1 error that occurred in A-Prompt and was apparent on the WebCT
course pages had to do with the use of scripts. A-Prompt suggests that all scripts have a "noscript"
section. This error was reported for many pages tested, but the only pages that caused a problem
18
in Lynx, where JavaScript was not available, were these WebCT course pages. Providing a
“noscript” alternative is one of the guidelines recommended by the UNB Web Team.
The Library Services Main Page and most of the Online Registration pages did not
display enlarged text when the browser settings were changed. Also, these pages had warnings in
Bobby to use relative sizing instead of absolute. Making this change would make these pages
more accessible to users with diminished eyesight.
Another re-occurring problem was tables that either did not transform well into text-only
mode, or produced errors in both Bobby and A-Prompt. There were many instances of tables
being used to layout the page, and according to the W3C guidelines this should be avoided.
However, according to the guidelines set in place by the Web Team, it is acceptable to use tables
for layout provided that the table is simple, so this technique may be used for the layout of the
pages tested as they all were easily navigated in Lynx. However, all of the data tables that were
difficult to read in Lynx should have their HTML checked out to ensure that it meets with
guidelines and the suggestions made by both Bobby and A-Prompt.
Another problem that stands out is that the frames for Student e-Services need to have
names provided that are descriptive as to their content. This was apparent in the Lynx testing, but
also appeared as a problem in both of the automated tests.
One error that re-occurred in the automated tests was with form controls and their labels.
The Bobby suggestion is to use the label statement to state which label goes with which control
so there will be no cause for confusion. Another re-occurring problem, which occurred for almost
every page, was that a DOCTYPE statement was missing for the page. Having this statement
makes a page more accessible to users who rely on screen readers.
Most of the users checks, and some of the other errors reported, did not apply to the
pages tested upon manual inspection. Although, there was not found any instances of this
manually, Bobby recommended not using the same link phrase more than once when the links
point to different URLs. A-Prompt also reported the error about link text not being meaningful,
19
however all of the links on the pages tested were clear and concise. Other errors that can be
disregarded include language changes not reported because the language of these pages does not
change, the image flicker warning can be ignored since none of the images flicker, the check if
colours contrast error can also be ignored as all colours on all the pages contrast and there were
no instances of colour alone being used to convey information.
So, it can be seen that although many of the errors reported by the automated tools are
real problems, there are also a good many errors that are false alarms. Considering the manual test
data along with the data from the automated tools, one can see that there are not as many
accessibility problems with these websites as reported by A-Prompt. Bobby seems to be more
accurate with its results, but when the manual checks are performed, it turns out that the page
does not have as many accessibility problems as reported. It seems that these utilities report more
errors than what actually occurs on the page so that the user is forced to test if these problems do
indeed exist. This is better than the alternative, where many manual checks may be overlooked if
a utility does not prompt the user to check these aspects manually.
6.0 Conclusions
Accessibility is important to ensure that websites have the largest possible audience. It is good
business sense for companies to ensure that their websites are accessible, not to mention an ethical and
legal requirement. Websites should follow the guidelines set in place by the World Wide Web
Consortium. While it is not a difficult task to ensure that a website follows these guidelines, it cannot be
accomplished by the use of an accessibility tool alone. Following suggestions from the W3C’s Web
Accessibility Initiative, some manual techniques must also be used to ensure a better understanding of
how the website will be perceived by persons with visual disabilities. By using manual techniques, along
with automated tools, developers can be sure that their website has the highest accessibility level possible.
20
Since it was found in these tests that automated tools err on the side of caution by reporting errors that
may or may not be on the page, it is also important to do some manual inspections of the pages tested.
During the testing of UNB Student e-Services and WebCT some problems were uncovered that
would make these websites inaccessible to students with visual disabilities. However, many of the
problems reported in A-Prompt and Bobby did not apply to the pages tested. The problems that do apply
to the pages tested are relatively easy to fix. Most of these problems are a result of the page not meeting
the guidelines set in place by the UNB Web Team. If the suggested changes are made to these UNB
websites then students with visual disabilities will be able to access web resources for UNB with minimal
difficulty.
7.0 Recommendations
During testing it was found that UNB e-Services and WebCT have some serious problems that
must be remedied to ensure that students with visual disabilities will be able to access these web resources
provided by the university. One recommendation that would make UNB websites more accessible is to
ensure that all images that are important to the navigation of a site, whether buttons or links, have alt text
provided. If these images are image maps with links, then these links should also be provided somewhere
else on the page. This is a simple step that will ensure that all users will be able to access UNB websites
with minimum difficulties.
Another recommendation is that any tables that do not transform well into a text-only browser be
fixed. This can be done by ensuring that proper HTML tags are used to markup tables, including table
headers and content. If this cannot be done, then the information should be made available in another
equivalent way.
There were some pages where the text size remained constant regardless of the browser settings,
so this also needs to be remedied. Following the recommendation of Bobby, all UNB web pages that do
not do this already should use relative instead of absolute positioning and sizing of page elements. This
21
will ensure that these pages are accessible to students with visual impairments who must be able to
enlarge the textual elements of web pages to read the information provided.
Other Priority 2 problems should also be fixed. The ones commonly found on the pages tested
were that a DOCTYPE statement should be used on every page. Another important recommendation is to
use the label statement to group together form controls and their labels. Also, auto-refresh causes
confusion for blind users, so if the WebMail Inbox is to be accessible to these users, then auto-refresh
must be removed.
One recommendation that will make e-Services easier to use for blind students is to give the
frames of the e-Services pages better names or even add descriptions that will give the user an indication
of the information available in each frame. This will make this website more accessible to students who
use the combination of a screen reader and a text-based browser to surf the Internet.
The WebCT Course pages must also be changed so that the course and quiz pages can be
negotiated in a browser with scripts disabled, like Lynx. This would involve having an alternative method
of interaction with the page. The suggestion by Bobby and A-Prompt is to specify the “noscript” section
of the pages’ script.
Fixing the Priority 1 and 2 errors will ensure that most users will be able to access and use the
UNB web resources. It is also recommended that the Priority 3 problems that apply to the pages tested be
remedied.
22
Bibliography
1. Brewer, Judy and Chuck Letourneau, eds. (Copyright 2001-2002). “Evaluating Web Sites for
Accessibility”. World Wide Web Consortium [homepage of W3C] [Online]. Available:
http://www.w3c.org/WAI/eval/ [Accessed 2003-01-15].
2. Brink, Tom, Darren Gergle and Scott D. Wood, Usability for the Web: Designing Web Sites
That Work, Morgan Kaufmann Publishers, San Francisco, 2002.
3. Chisholm, Wendy, Gregg Vanderheiden and Jan Jacobs, eds, (07-2001). “Web content
accessibility guidelines 1.0”. Communications of the ACM. [Online], v(n). Available:
http://ridgerat.hil.unb.ca:2197/10.1145/380000/379550/p35chisholm.pdf?key1=379550&key2=7821791401&coll=ACM&dl=ACM&CFID=667364
7&CFTOKEN=33577366 [Accessed 2003-01-07].
4. CITA. (August 15, 2000). “Check Your Page 3.2”. [Online]. Available:
http://w3.gsa.gov/web/m/old_cita.nsf/CheckYourPage [Accessed: 2003-01-15].
5. Hall, Rik. Manager of Instructional Technology, Integrated Technology Services, University of
New Brunswick, Fredericton, New Brunswick. Email to Christa Welton, February 21,
2003.
6. Jarrett, Caroline, (07-2001).”‘How to’ manual on forms design”. Communications of the ACM.
[Online], v(n). Available: http://ridgerat.hil.unb.ca:2197/10.1145/510000/501080/p4jarrett.pdf?key1=501080&key2=8642791401&coll=ACM&dl=ACM&CFID=6673647&
CFTOKEN=33577366 [Accessed 2003-01-07].
7. Laux, Lila F., Peter R. McNally, Micheal G. Paciello and Gregg Vanderheiden, (1996).
“Designing the World Wide Web for people with disabilities: a user centered design
approach”. Communications of the ACM. [Online], v(n). Available:
http://ridgerat.hil.unb.ca:2197/10.1145/230000/228363/p94laux.pdf?key1=228363&key2=2861791401&coll=ACM&dl=ACM&CFID=6673647&C
FTOKEN=33577366 [Accessed 2003-01-07].
8. Nielsen, Jakob. (Copyright 2001-11-11). “Beyond Accessibility: Treating Users with
Disabilities as People”. [Online]. Available:
http://www.useit.com/alertbox/20011111.html [Accessed: 2003-01-15].
9. Nielsen, Jakob, Designing Web Usability: The Practise of Simplicity, New Riders Publishing,
Indianapolis, Indiana, 2000.
10. Nielsen, Jakob. (Copyright 1999-06-13). “Disabled Accessibility: The Pragmatic Approach”.
[Online]. Available: http://www.useit.com/alertbox/990613.html [Accessed: 2003-0115].
23
11. Nielsen, Jakob. (Copyright 2002-10-14). “Making Flash Usable for Users With Disabilities”.
[Online]. Available: http://www.useit.com/alertbox/20021014.html [Accessed: 2003-0115].
12. Nielsen, Jakob, Usability Engineering, Academic Press, San Diego, California, 1993.
13. Rowan, Murray, Peter Gregor, David Sloan and Paul Booth, (11-2000). “Evaluating web
resources for disability access”. Communications of the ACM. [Online], v(n). Available:
http://ridgerat.hil.unb.ca:2197/10.1145/360000/354346/p80rowan.pdf?key1=354346&key2=1070791401&coll=GUIDE&dl=GUIDE&CFID=66736
47&CFTOKEN=33577366 [Accessed 2003-01-07].
14. Scholtz, Jean and John Thomas, eds, Conference on Universal Usability: CUU 2000
Conference Proceedings. Association for Computing Machinery Press, New York, 2000.
15. Sierkoroski, Brian, (11-2002). “Achieving web accessibility”. Communications of the ACM.
[Online], v(n). Available: http://ridgerat.hil.unb.ca:2197/10.1145/590000/588725/p288sierkowski.pdf?key1=588725&key2=2662791401&coll=ACM&dl=ACM&CFID=66736
47&CFTOKEN=33577366 [Accessed 2003-01-07].
16. Stewart, Megan, Publications Coordinator, Integrated Technology Services (Virtual Member
of UNB Web Team), University of New Brunswick, Fredericton, New Brunswick, in
conversation with Christa Welton, February 10, 2003.
17. Vanderheiden, Gregg, (11-2000). “Fundamental principles and priority setting for universal
usability”. Communiations of the ACM. [Online], v(n). Available:
http://ridgerat.hil.unb.ca:2197/10.1145/360000/355469/p32vanderheiden.pdf?key1=355469&key2=7901791401&coll=ACM&dl=ACM&CFID=667
3647&CFTOKEN=33577366 [Accessed 2003-01-07].
18. Unknown. (Copyright 2002-2002). “Bobby”. WatchFire Corporation [Online]. Available:
http://bobby.watchfire.com/bobby/html/en/index.jsp [Accessed 2003-01-15].
19. Unknown. (Updated 1998-07). “Government of Canada Internet Guide”. Government of
Canada [Online]. Available: http://canada.gc.ca/programs/guide/3_1_4e.html [Accessed:
2003-01-20].
20. Unknown. (Updated 2002-12-11). “C.L.F.- Accessibility Section”. Treasury Board of Canada
Secretariat. Available: http://www.cio-dpi.gc.ca/clf-upe/1/1_e.asp [Accessed: 2003-0120].
21. Unknown. “A-Prompt Project”. A-Prompt [homepage of A-Prompt]. Available:
http://aprompt.snow.utoronto.ca/index.html [Accessed: 2003-01-20].
22. Unknown. “UNB Web Development Team- Accessibility and the UNB Website”. UNB
Integrated Technology Services. Available:
http://www.unb.ca/webteam/accessibility.html [Accessed: 2003-01-31].
24
Appendix A: A-Prompt Results for UNB
Student e-Services
The Login Page for UNB e-Services had 17 errors when tested with A-Prompt. However,
many of the problems that A-Prompt found, when tested manually, proved to be false alarms. For
example, one of the problems was that A-Prompt reported that the UNB logo was flickering, but
since it was not, this can be ignored. However, alt text or a description was not provided for the
logo. The UNB Pin textbox did not have a label and the language of the page was not identified.
There was also concern about the use of tables to layout the information on the page.
The main page of UNB e-Services also failed A-Prompt testing. The complaints were that
while the frames were both named (tabs and main) each frame did not have a title. This is a
Priority 1 failure. A Priority 2 failure was that an alternative was not provided for browsers that
do not support frames. This can be remedied by adding a NOFRAMES section to the
FRAMESET. A priority three failure was that the page language was not identified.
The UNB e-Services Academic Main Page also failed A-Prompt testing with 8 errors.
This page had the same errors as the e-Services Main Page and also another Priority 2 error that
suggested that the frames might need a description. The UNB e-Services Personal Page also had
the same problems. The UNB e-Services Library Page had only 5 errors. However, none of these
were new, in that they were common errors on the other e-Services pages.
Under the Academic tab the Apply for Scholarships Page had 140 errors. The errors
found on this page are common throughout the e-Services pages. The Priority 1 errors were that
flicker should be avoided, images missing alt text, images missing descriptive text, script missing
"noscript" section, and some manual checks that included colour alone should not be used to
convey information, language changes should be indicated, programmatic object may not be
accessible, programmatic object may require testing, text equivalents require updating, and this
25
document does not use styles or style sheets. The Priority 2 errors were input label missing
(however, the label is beside the box), link text may not be meaningful and table may not
linearize properly. The Priority 3 errors were that the colour contrast was low, input missing
default text (which didn’t seem necessary for this page), language not identified and table missing
summary. Similar Priority 1, 2 and 3 errors were found in the other Academic Services pages
tested, but to a lesser degree. The Class Schedule Page had 24 problems, the Exam Schedule Page
had 14 problems and the View Marks/Unofficial transcript Page had 73 problems. These
problems were either all of the ones listed above, or a subset of the problems listed.
The Computing – Change Pin Page had 17 problems. The Priority 1 errors included
flicker should be avoided, image missing alt and descriptive text and the manual checks colour
alone should not be used to convey information, language changes not indicated, and this
document does not use styles or style sheets. The Priority 2 errors included headers may require
markup, label missing for input (it was right beside the box), link text may not be meaningful,
new window requires warning anchor, table may not linearize properly and table headers are
invalid. The Priority 3 errors included language not identified and table missing summary. The EMail Check Quota Page had 19 problems, all of which are the same as above, except A-Prompt
found the Priority 2 error DOCTYPE missing instead of the new window warning error. APrompt also found the Priority 3 error colour contrast low.
The E-Mail WebMail Inbox Page had 97 problems. The Priority 1 errors were that flicker
should be avoided, images missing alt text, images missing descriptive text, script missing
noscript section, and some manual checks that included colour alone should not be used to
convey information, language changes should be indicated, programmatic object may not be
accessible, programmatic object may require testing, text equivalents require updating, and this
document does not use styles or style sheets, and script missing “noscript” section. The Priority 2
errors included auto-refresh must be removed, label missing for selection box, script not keyboard
accessible, link text may not be meaningful, table may not linearize properly and table missing
26
caption. The Priority 3 errors included colour contrast low, language not identified, table headers
are invalid and table may require header abbreviations.
The Financial- Buy Print Credits Page had 19 problems. The Priority 1 errors included
flicker should be avoided, image missing descriptive text, and the manual checks: colour should
not be used to convey information alone, language changes not indicated, and this document does
not use styles or stylesheets. The Priority 2 errors included DOCTYPE missing, label missing for
input box, link text may not be meaningful, table may not linearize properly and table headers are
invalid. The Priority 3 errors included colour contrast low, input missing default text, language
not identified, and table missing summary. The Financial- Fee Statement Page also had 19 errors.
It had the same Priority 1 errors as above with the addition of table may require mark up and table
missing headers. It also had all the same Priority 2 and 3 errors as the Buy Print Credits Page
except for the Priority 2 errors DOCTYPE missing and label missing for input box
Library Services – Quest Page had 38 problems. The Priority 1 errors included flicker
should be avoided, images missing alt text, images missing descriptive text, script missing
“noscript” section, and some manual checks that included colour alone should not be used to
convey information, language changes should be indicated, programmatic object may not be
accessible, programmatic object may require testing, text equivalents require updating, and this
document does not use styles or style sheets. Priority 2 errors included DOCTYPE missing, label
missing for input box, link text may not be meaningful, and table may not linearize properly. The
Priority 3 errors included colour contrast low, input missing default text, language not identified,
and table missing summary.
Library Services Quest Search Results page had 103 problems. The Priority 1 errors
included flicker should be avoided, images missing descriptive text, table may require markup,
table missing headers, script missing “noscript” section, and some manual checks that included
colour alone should not be used to convey information, language changes should be indicated,
programmatic object may not be accessible, programmatic object may require testing, text
27
equivalents require updating, and this document does not use styles or style sheets. Priority 2
errors included input label missing (36 instances, although the label is directly above the input
box), link text may not be meaningful, table missing caption, and DOCTYPE missing. The
Priority 3 errors were colour contrast low, input missing default text, language not identified,
table without summary and table may require header abbreviations.
The Personal- Demographics Page had 86 problems. The Priority 1 errors included
flicker should be avoided, image missing descriptive text, and the manual checks: colour alone
should not be used to convey information, language changes not indicated. And this document
does not use styles or style sheets. The Priority 2 errors included label missing for selection box
(it has a label beside it), table may not linearize properly, table headers are invalid, and headers
may require markup. The Priority 3 errors included text area missing default text, colour contrast
low, input missing default text, language not identified, and table missing summary.
There were also many errors reported with the Online Registration pages. The Priority 1 errors
that could not be dismissed when evaluated manually and were common
throughout all the pages included image missing alternative and descriptive text,
script missing no “script” section (for if the browser does not support scripts),
and multiple links missing skip over. Priority 2 errors included headers may
require mark-up, link text may not be meaningful, list usage invalid (it was used
to format text), new window requiring warning (there is a link that opens a new
window and a warning is required) and table may not linearize properly, the
headers were invalid and DOCTYPE missing. Priority 3 errors that remained
after manual evaluation were that the language of the page was not identified,
tables did not have a summary, colour contrast for the page was low, image map
missing text links, multiple links missing skip over and table missing summary,
and image links also required backup text links for text-only browsers.
The UNB Online Registration- Register for Courses page had 118 errors. What caused
the bulk of the errors was the fact that the textboxes and drop down lists did not have default
entries, which is not appropriate for this page. There were thirty instances of this problem. There
were also 60 instances of an input field not having a label. Since this input form is presented as a
table it has been designed so that the label for each column is at the top of the column. As long as
the table transforms well into a text-based browser there is no need for each individual input field
to have its own label.
28
Appendix B: Bobby Results for UNB Student e-Services
The login page for UNB e-Services failed AAA compliance testing. Bobby found one
Priority 1 error that there was not alternative text for the UNB logo. There were also seven things
that needed to be manually checked, but these all met with regulations upon examination. There
were three Priority 2 errors that were found with the page. This included the recommendation of
using relative sizing instead of the absolute sizing that was used. Bobby reported 20 instances of
this error. Other concerns included using “ a public text identifier in a DOCTYPE statement” and
“explicitly associate form controls and their labels with the LABEL element.” There were 8 user
checks that also needed to be completed to ensure that the page conformed. These had to do with
forms, layouts, colour contrast, and images. All of these user checks passed. There were also
seven other user checks that needed to be performed. These user checks appear in the report
whether they are applicable to your page or not, but they need to be checked to ensure that your
page complies with the regulations. There were three recommendations for Priority 3 level
changes. These were to provide a summary for tables (tables were used in this case not for data
but for the layout of the page), provide information as to the language of the page and to have
default values in textboxes as place holders (these place holder could have been, for instance,
username and password). There were also some user checks that needed to be performed that had
to do with checking if keyboard shortcuts would be appropriate if not already available and there
were also some concerns over the use of a table for the page layout.
The Online Registration had some errors that need to be corrected before it can be
considered compliant under Bobby testing. There one Priority 1 error was for instances of images
without alt text. The Priority 2 errors were that relative sizing should be used instead of absolute,
a DOCTYPE statement should be used, and make sure that event handlers are accessible without
a mouse. The Priority 3 errors included provide a summary for tables, identify the language of the
29
text, and to separate adjacent links with more than just white space. There were also some user
checks, but these passed.
The Online Registration Main Page also failed Bobby testing. Again it had the same
Priority 1 error of providing alt text for all images. And it also had the Priority 2 error that relative
sizing should be used instead of absolute. Priority 3 errors included a summary should be
provided for tables, identify language of the text and that the client-side image map contains a
link that is not presented anywhere else on the page.
The Online Registration- Search for Classes page had the same Priority 1 error as the
previous page. The Priority 2 errors included that relative sizing and positioning should be used
rather than absolute, use a public text identifier in a DOCTYPE statement and explicitly associate
form controls and their labels with the label statement. Priority 3 errors included that a summary
should be provided for tables, the language of the text should be identified, include default placeholder values in edit boxes and text areas, and that the client side image map contains links that
are not available anywhere else on the page. Some user checks included consider grouping long
lists of selections into a hierarchy, check if colours contrast, if there are logical groupings of form
controls use FIELDSET with LEGEND for each group, avoid use of obsolete language features if
possible, if table used for layout do not use structure markup to achieve formatting effects, and
make sure that the user is aware of pop-ups or changes in the active window.
The Library Services Quest page had one Priority 1 error, to provide alt text for all
images. The Priority 2 errors were to use relative sizing and positioning, use a public text
identifier DOCTYPE statement, explicitly associate form controls and their labels with the
LABEL element, do not cause a page to redirect to a new URL, and do not use the same link
phrase more than once when the links point to different URLs. Some Priority 3 errors included
provide a summary for tables, identify language of the text, include default place-holding
characters in edit boxes and text areas, and separate adjacent links with more than white space.
30
Appendix C: A-Prompt Results for WebCT
The WebCT Login Page had 21 errors when tested with A-Prompt. Priority 1 failures
included flicker in images, “image map AREA missing alternative text”, not having a description
or alternative text for images (WebCT logo) and some manual checks included checking if colour
was used to convey information, checking for language changes on the page, and checking
whether the page requires the use of style sheets. Priority 2 concerns were that the headers on the
page may require markup, link text may not be meaningful and the layout table may not linearize
properly. Priority 3 concerns included low colour contrast, page language not identified, multiple
links missing skip over and table missing summary.
In the My WebCT Main Page, there were 53 errors reported. The one different type of
error from the Login page was a script was found that was not keyboard accessible. This is a
Priority 2 concern. These script events are dependent on the use of a mouse. A-Prompt can
automatically fix these errors.
In the WebCT Course Page there were 10 problems. The Priority 1 errors were script missing
“noscript” section and the manual checks: language changes not indicated,
programmatic object may not be accessible, programmatic object may require
testing, and text equivalents require updating. The Priority 2 errors found were
script not keyboard accessible and table may not linearize properly. The Priority
3 errors were colour contrast low and table missing summary.
The WebCT Quiz Instructions Page had 17 problems. These were all the same as the
Course page with the addition of one more Priority 2 error that link text may not be meaningful.
The WebCT Quiz Page had 46 problems. The Priority 1 errors included image missing alt and
descriptive text, script missing “noscript” section and the manual checks language changes not
indicated, programmatic object may not be accessible, programmatic object may require testing
and text equivalents require updating. The Priority 2 errors included script not keyboard
accessible and table may not linearize properly. The Priority 3 errors included colour contrast
low, language not identified, and table missing summary.
31
Appendix A: A-Prompt Results for UNB
Student e-Services
The Login Page for UNB e-Services had 17 errors when tested with A-Prompt. However,
many of the problems that A-Prompt found, when tested manually, proved to be false alarms. For
example, one of the problems was that A-Prompt reported that the UNB logo was flickering, but
since it was not, this can be ignored. However, alt text or a description was not provided for the
logo. The UNB Pin textbox did not have a label and the language of the page was not identified.
There was also concern about the use of tables to layout the information on the page.
The main page of UNB e-Services also failed A-Prompt testing. The complaints were that
while the frames were both named (tabs and main) each frame did not have a title. This is a
Priority 1 failure. A Priority 2 failure was that an alternative was not provided for browsers that
do not support frames. This can be remedied by adding a NOFRAMES section to the
FRAMESET. A priority three failure was that the page language was not identified.
The UNB e-Services Academic Main Page also failed A-Prompt testing with 8 errors.
This page had the same errors as the e-Services Main Page and also another Priority 2 error that
suggested that the frames might need a description. The UNB e-Services Personal Page also had
the same problems. The UNB e-Services Library Page had only 5 errors. However, none of these
were new, in that they were common errors on the other e-Services pages.
Under the Academic tab the Apply for Scholarships Page had 140 errors. The errors
found on this page are common throughout the e-Services pages. The Priority 1 errors were that
flicker should be avoided, images missing alt text, images missing descriptive text, script missing
"noscript" section, and some manual checks that included colour alone should not be used to
convey information, language changes should be indicated, programmatic object may not be
accessible, programmatic object may require testing, text equivalents require updating, and this
32
document does not use styles or style sheets. The Priority 2 errors were input label missing
(however, the label is beside the box), link text may not be meaningful and table may not
linearize properly. The Priority 3 errors were that the colour contrast was low, input missing
default text (which didn’t seem necessary for this page), language not identified and table missing
summary. Similar Priority 1, 2 and 3 errors were found in the other Academic Services pages
tested, but to a lesser degree. The Class Schedule Page had 24 problems, the Exam Schedule Page
had 14 problems and the View Marks/Unofficial transcript Page had 73 problems. These
problems were either all of the ones listed above, or a subset of the problems listed.
The Computing – Change Pin Page had 17 problems. The Priority 1 errors included
flicker should be avoided, image missing alt and descriptive text and the manual checks colour
alone should not be used to convey information, language changes not indicated, and this
document does not use styles or style sheets. The Priority 2 errors included headers may require
markup, label missing for input (it was right beside the box), link text may not be meaningful,
new window requires warning anchor, table may not linearize properly and table headers are
invalid. The Priority 3 errors included language not identified and table missing summary. The EMail Check Quota Page had 19 problems, all of which are the same as above, except A-Prompt
found the Priority 2 error DOCTYPE missing instead of the new window warning error. APrompt also found the Priority 3 error colour contrast low.
The E-Mail WebMail Inbox Page had 97 problems. The Priority 1 errors were that flicker
should be avoided, images missing alt text, images missing descriptive text, script missing
noscript section, and some manual checks that included colour alone should not be used to
convey information, language changes should be indicated, programmatic object may not be
accessible, programmatic object may require testing, text equivalents require updating, and this
document does not use styles or style sheets, and script missing “noscript” section. The Priority 2
errors included auto-refresh must be removed, label missing for selection box, script not keyboard
accessible, link text may not be meaningful, table may not linearize properly and table missing
33
caption. The Priority 3 errors included colour contrast low, language not identified, table headers
are invalid and table may require header abbreviations.
The Financial- Buy Print Credits Page had 19 problems. The Priority 1 errors included
flicker should be avoided, image missing descriptive text, and the manual checks: colour should
not be used to convey information alone, language changes not indicated, and this document does
not use styles or stylesheets. The Priority 2 errors included DOCTYPE missing, label missing for
input box, link text may not be meaningful, table may not linearize properly and table headers are
invalid. The Priority 3 errors included colour contrast low, input missing default text, language
not identified, and table missing summary. The Financial- Fee Statement Page also had 19 errors.
It had the same Priority 1 errors as above with the addition of table may require mark up and table
missing headers. It also had all the same Priority 2 and 3 errors as the Buy Print Credits Page
except for the Priority 2 errors DOCTYPE missing and label missing for input box
Library Services – Quest Page had 38 problems. The Priority 1 errors included flicker
should be avoided, images missing alt text, images missing descriptive text, script missing
“noscript” section, and some manual checks that included colour alone should not be used to
convey information, language changes should be indicated, programmatic object may not be
accessible, programmatic object may require testing, text equivalents require updating, and this
document does not use styles or style sheets. Priority 2 errors included DOCTYPE missing, label
missing for input box, link text may not be meaningful, and table may not linearize properly. The
Priority 3 errors included colour contrast low, input missing default text, language not identified,
and table missing summary.
Library Services Quest Search Results page had 103 problems. The Priority 1 errors
included flicker should be avoided, images missing descriptive text, table may require markup,
table missing headers, script missing “noscript” section, and some manual checks that included
colour alone should not be used to convey information, language changes should be indicated,
programmatic object may not be accessible, programmatic object may require testing, text
34
equivalents require updating, and this document does not use styles or style sheets. Priority 2
errors included input label missing (36 instances, although the label is directly above the input
box), link text may not be meaningful, table missing caption, and DOCTYPE missing. The
Priority 3 errors were colour contrast low, input missing default text, language not identified,
table without summary and table may require header abbreviations.
The Personal- Demographics Page had 86 problems. The Priority 1 errors included
flicker should be avoided, image missing descriptive text, and the manual checks: colour alone
should not be used to convey information, language changes not indicated. And this document
does not use styles or style sheets. The Priority 2 errors included label missing for selection box
(it has a label beside it), table may not linearize properly, table headers are invalid, and headers
may require markup. The Priority 3 errors included text area missing default text, colour contrast
low, input missing default text, language not identified, and table missing summary.
There were also many errors reported with the Online Registration pages. The Priority 1 errors
that could not be dismissed when evaluated manually and were common
throughout all the pages included image missing alternative and descriptive text,
script missing no “script” section (for if the browser does not support scripts),
and multiple links missing skip over. Priority 2 errors included headers may
require mark-up, link text may not be meaningful, list usage invalid (it was used
to format text), new window requiring warning (there is a link that opens a new
window and a warning is required) and table may not linearize properly, the
headers were invalid and DOCTYPE missing. Priority 3 errors that remained
after manual evaluation were that the language of the page was not identified,
tables did not have a summary, colour contrast for the page was low, image map
missing text links, multiple links missing skip over and table missing summary,
and image links also required backup text links for text-only browsers.
The UNB Online Registration- Register for Courses page had 118 errors. What caused
the bulk of the errors was the fact that the textboxes and drop down lists did not have default
entries, which is not appropriate for this page. There were thirty instances of this problem. There
were also 60 instances of an input field not having a label. Since this input form is presented as a
table it has been designed so that the label for each column is at the top of the column. As long as
the table transforms well into a text-based browser there is no need for each individual input field
to have its own label.
35
Appendix B: Bobby Results for UNB Student e-Services
The login page for UNB e-Services failed AAA compliance testing. Bobby found one
Priority 1 error that there was not alternative text for the UNB logo. There were also seven things
that needed to be manually checked, but these all met with regulations upon examination. There
were three Priority 2 errors that were found with the page. This included the recommendation of
using relative sizing instead of the absolute sizing that was used. Bobby reported 20 instances of
this error. Other concerns included using “ a public text identifier in a DOCTYPE statement” and
“explicitly associate form controls and their labels with the LABEL element.” There were 8 user
checks that also needed to be completed to ensure that the page conformed. These had to do with
forms, layouts, colour contrast, and images. All of these user checks passed. There were also
seven other user checks that needed to be performed. These user checks appear in the report
whether they are applicable to your page or not, but they need to be checked to ensure that your
page complies with the regulations. There were three recommendations for Priority 3 level
changes. These were to provide a summary for tables (tables were used in this case not for data
but for the layout of the page), provide information as to the language of the page and to have
default values in textboxes as place holders (these place holder could have been, for instance,
username and password). There were also some user checks that needed to be performed that had
to do with checking if keyboard shortcuts would be appropriate if not already available and there
were also some concerns over the use of a table for the page layout.
The Online Registration had some errors that need to be corrected before it can be
considered compliant under Bobby testing. There one Priority 1 error was for instances of images
without alt text. The Priority 2 errors were that relative sizing should be used instead of absolute,
a DOCTYPE statement should be used, and make sure that event handlers are accessible without
a mouse. The Priority 3 errors included provide a summary for tables, identify the language of the
36
text, and to separate adjacent links with more than just white space. There were also some user
checks, but these passed.
The Online Registration Main Page also failed Bobby testing. Again it had the same
Priority 1 error of providing alt text for all images. And it also had the Priority 2 error that relative
sizing should be used instead of absolute. Priority 3 errors included a summary should be
provided for tables, identify language of the text and that the client-side image map contains a
link that is not presented anywhere else on the page.
The Online Registration- Search for Classes page had the same Priority 1 error as the
previous page. The Priority 2 errors included that relative sizing and positioning should be used
rather than absolute, use a public text identifier in a DOCTYPE statement and explicitly associate
form controls and their labels with the label statement. Priority 3 errors included that a summary
should be provided for tables, the language of the text should be identified, include default placeholder values in edit boxes and text areas, and that the client side image map contains links that
are not available anywhere else on the page. Some user checks included consider grouping long
lists of selections into a hierarchy, check if colours contrast, if there are logical groupings of form
controls use FIELDSET with LEGEND for each group, avoid use of obsolete language features if
possible, if table used for layout do not use structure markup to achieve formatting effects, and
make sure that the user is aware of pop-ups or changes in the active window.
The Library Services Quest page had one Priority 1 error, to provide alt text for all
images. The Priority 2 errors were to use relative sizing and positioning, use a public text
identifier DOCTYPE statement, explicitly associate form controls and their labels with the
LABEL element, do not cause a page to redirect to a new URL, and do not use the same link
phrase more than once when the links point to different URLs. Some Priority 3 errors included
provide a summary for tables, identify language of the text, include default place-holding
characters in edit boxes and text areas, and separate adjacent links with more than white space.
37
Appendix C: A-Prompt Results for WebCT
The WebCT Login Page had 21 errors when tested with A-Prompt. Priority 1 failures
included flicker in images, “image map AREA missing alternative text”, not having a description
or alternative text for images (WebCT logo) and some manual checks included checking if colour
was used to convey information, checking for language changes on the page, and checking
whether the page requires the use of style sheets. Priority 2 concerns were that the headers on the
page may require markup, link text may not be meaningful and the layout table may not linearize
properly. Priority 3 concerns included low colour contrast, page language not identified, multiple
links missing skip over and table missing summary.
In the My WebCT Main Page, there were 53 errors reported. The one different type of
error from the Login page was a script was found that was not keyboard accessible. This is a
Priority 2 concern. These script events are dependent on the use of a mouse. A-Prompt can
automatically fix these errors.
In the WebCT Course Page there were 10 problems. The Priority 1 errors were script missing
“noscript” section and the manual checks: language changes not indicated,
programmatic object may not be accessible, programmatic object may require
testing, and text equivalents require updating. The Priority 2 errors found were
script not keyboard accessible and table may not linearize properly. The Priority
3 errors were colour contrast low and table missing summary.
The WebCT Quiz Instructions Page had 17 problems. These were all the same as the
Course page with the addition of one more Priority 2 error that link text may not be meaningful.
The WebCT Quiz Page had 46 problems. The Priority 1 errors included image missing alt and
descriptive text, script missing “noscript” section and the manual checks language changes not
indicated, programmatic object may not be accessible, programmatic object may require testing
and text equivalents require updating. The Priority 2 errors included script not keyboard
accessible and table may not linearize properly. The Priority 3 errors included colour contrast
low, language not identified, and table missing summary.
38
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising