Accessibility Report for Sakai Open Academic Environment (OAE) Version 1.1

goldbashedAI and Robotics

Nov 15, 2013 (3 years and 8 months ago)

155 views











Accessibility Report

for

Sakai Open Academic Environment (OAE)

V
ersion 1.1


Sakai Accessibility Working Group


June

1
st
, 2012



Report Summary


This report provides an accessibility analysis and evaluation of Sakai’s Open Academic Environment
(OAE)

V
ersion 1.1
.
The
Sakai
Accessibility Working Group evaluated the Sakai Open Academic
Environment Version 1.1 (henceforth referred to as Sakai OAE v1.1) for accessibility issues against the
W3C
Web Content Accessibility Guidelines
(WCAG)

2.0 level A a
nd AA
success
cri
teria utilizing both
evaluation/
testing protocols and
multiple
types of assistive technology.
The complete results and
methods are publically available on the Sakai Accessibility Working Group

s confluence wiki pages under
the heading
Sakai OAE v1.1 Accessibility review
(
https://confluence.sakaiproject.org/display/2ACC/Sakai+OAE+v1.1+Accessibility+Review
).
Any
questions or concerns abou
t this report can be addressed to the Sakai Accessibility Working Group
(email:
accessibility@collab.sakaiproject.org
).

The evaluation found that the accessibility of Sakai OAE
has improved,

incl
uding: keyboard accessibility
of the top navigation, accessible gritter notifications, labeling of unlabeled form controls, left navigation
keyboard accessibility, form validation, default langu
age, grouping items into lists and
alternative text
descriptio
ns.

However,
numerous functional and technical accessibility issues across multiple functi
onal
areas
still exist
in Sakai OAE v1.1.
Some of the issues that could prevent users with disabilities from
accessing the core functionalities and features of Sakai
OAE

include, but are not limited to
:
keyboard
in
accessibility, keyboard trap
,
lost
control of focus, visual indication of focus, unlabeled/non
-
unique
form controls
and
non
-
unique/confusing web links
.


The evaluation found
that the accessibility of Sakai OAE v1.1 falls short of
both
the minimum
accessibility
standards
(WCAG 2.0 Level A and AA Success Criteria and the Authoring Tool Accessibility
Guidelines [ATAG]) set forth in the Sakai OAE Accessibility statement
(
http://www.sakaiproject.org/accessibility
)
as well as the accessibility goals of other comparable LMS
ecosystems
. Many of the issues found during the evaluation occurred in multiple functional areas and
wid
gets. These issues require both immediate remediation and signal that
part of the

underlying
problem
is
that accessibility guidelines have not been followed during the design and development
phases of Sakai OAE.
The Sakai Accessibility Working Group des
ires to avoid
a cycle of constant
remediation, which will be expensive,
slows down releases

and put users with disabilities at a
disadvantage.
Therefore, t
he
Sakai Accessibility Working Group

proposes the following
r
ecommendations
:



Require that all develop
ers have a basic level of understanding in accessibility evaluation,
design and development techniques
and
provide training for developers who do not meet this
requirement.



Develop a semantic affordance style guide that includes accessible design and devel
opment
patterns.



Create a developers c
hecklist distilled from the WCAG success criteria and ATAG

and
supplemented by the semantic affordance style guide
.



Develop testing protocols

for newly developed widgets and functional areas that automatically
validate (where possible) against the WCAG
2.0 success criteria.



Incorporate accessibility testing
and the semantic affordance style guide
into the Quality
Assurance testing phase to ident
ify accessibility issues before a version release.



Include accessibility experts in the design
and requirements gathering phases

of

new
and
redesigned
features, so that potential accessibility considerations may be addressed
.



Develop an accessibility roadmap and if needed accessible alternatives so the general public is
aware of the accessibility status and remediation efforts
.

This report acknowledges
that this
a
ccessibility evaluation

had limitations. Some of the limitations
include:
rapid
release schedule of Sakai OAE, multiple functional areas and widgets were not evaluated

due to limited resources and time
, issues inherent in the technology used for testing and remediation
completed during the evaluation.

Expanded Details
about the
Accessibility Issues

Each WCAG 2.0 Success criterion failure has been condensed into categories with related accessibility
issues for brevity. An appendix has been included with the complete breakdown of WCAG 2.0 successes
and failures.

Keyboar
d Accessibility

Keyboard accessibility is critical f
or many users with disabilities
particularly users of screen
reading software and non
-
mouse users.
For these users
,

it is their only means of accessing a
computer.
Numerous components, features and widgets have HTML elements, which cannot be
accessed using the keyboard.
Most of the keyboard accessibility issues can be categorized in
to
one or more the following categories:




Clickable HTML

elements that cannot receive

keyboard input
/visual focus



Content areas that trap keyboard focus

so use
r
s cannot easily navigate away from the
area



HTML elements that do not
display adequate visual indication of focus



HTML elements received focus in an order that does not match the vi
sual layout

The t
hree Sakai OAE features/
widgets, which have the most significant issues,

include: the
c
ontent authoring WYSIWYG editor,
t
he suggested content carousel on
My dashboard

and the
n
avigation tree in the
Assign a Category

modal dialogue.

Some
accessibility
i
mprovements have been made in
Sakai OAE
releases leading up to v1.1
, are
currently in remediation or
have been fixed in future releases.
These include:



Keyboard accessibility of the
t
op
n
avigation area

(prior to v1.1)



Improved keyboard focus

of the left hand navigation (included in 1.3.0
,

targeted

in
1.5.0)



Containing
k
eyboard focus in modal dialogs (fixed 1.2.0)

However
,
some
newly developed

features/widgets exhibit the
se

same keyboard accessibility
issues.

Semantics

Proper semantic coding greatly improves the ability for users
with disabilities
to navigate and
understand Web page content.

Most of the semantic accessibility issues can be categorized into
one or more the following categories:




Inadequate or missing
heading structure for important area
s

of
each

page



Groups of links or content are
not
marked up as HTML lists



Non
-
u
nique page title
s



F
orm controls
that
are
not
uniquely and explicitly labeled



Missing
Skip navigation
/
skip to content

links

Non
-
unique page ti
tles are an issue because p
age titles are the first piece of content presented
to users of adaptive technology and the title confirms they are in the correct place.
An
adequate h
eading

s
tructure is important because it

give
s

users an overview of the

important
areas of a

page
.
H
eadings, HTML

lists and skip navigation links
,

provide ways to bypass
and
navigate
content
. When these features are missing, users of adaptive technology must navigate
through the entire page to find their desired content
. With
out form control labels most users
with disabilities would not be able to determine the purpose of a form control.

These issues
were encountered in every feature/widget

of Sakai OAE v1.1.

Some
accessibility
i
mprovements have been made in Sakai OAE releases

leading up to v1.1, are
currently in remediation or have been fixed in future releases. These include:



Labeled previ
ously unlabeled
comments textarea (prior to v1.1)



Marked up “tags” and search results as an HTML list (prior to v1.1)



Added skip navigation

(
included
1.3.0
,
targeted
1.5.0
)



ARIA landmark
s

added (targeted 1.5.0)



Labeled top navigation submit button,
My library

“remove” checkboxes,
My messages

inbox checkboxes and “delete message” buttons

(
fixed
1.2.0)



Improved
h
eading structure on all pages
(fixed 1.3.0)

However,
some
newly developed features/widgets exhibit these same semantic accessibility
issues.

HTML links

HTML links are the primary means of navigating the World Wide Web, something many people
take for granted because identifying and acce
ssing
Web
links ha
s

become second nature.
For

many users of adaptive technology
,

the visual context most

people use to separate one link
from another is missing. Therefore, all links
must

be unique and describe the purpose of the
link
. Unfortunately, a s
ignificant number of links in Sakai OAE are not unique and descriptive.

Some
accessibility
improvements have been made in Sakai OAE releases leading up to v1.1, are
currently in remediation or have been fixed in future releases. These include:



Memberships,

content items, parti
ci
pants link
s

(targeted

1.5.0)




My messages inbox “reply” links (fixed 1.2.0)



Top Navigation inbox and collections link (fixed 1.2.0)

However,
some
newly developed features/widgets exhibit
these same
Non
-
unique hyperlink
text
issues.

Alternative Text Descriptions

Alternative text

descriptions are one of the only

way
s

a user with a disability can access a piece
of non
-
text content (e.g., images)
. Therefore, all non
-
text content should have unique
alternative text descriptions. Multiple Sakai OAE features/widgets contain
images with non
-
unique, inadequate or missing, alternative text descriptions. These issues have yet to be
addressed as part of t
he ongoing remediation of Sakai OAE and may occur in newly developed
features/widgets.

Color Contrast

If HTML elements do not meet the minimum color contrast ratio specified by WCAG 2.0 success
criterion Level AA 1.4.3 of 4.5:1, users with disabilities inc
luding low vision and color blindness
will not be able to read the offending content. The failure to meet the minimum color contrast
ratio is wide spread
,

a
ffecting

most Sakai OAE features and widgets
.
The implementation of a
color style guide could help
avoid future color contrast issues.
Improvements to color contrast
are part of the ongoing remediation efforts, but no color contrast issue has been completely
fixed
as of the

conclusion of this review.

Resizable text

The ability to resize text/ enlarge t
he font

of a Web page without full page enlargement is
helpful to many users with disabilities, the elderly and
users of
devices with low screen
resolutions. When enlarging a Web page with full page enlargement, users will most likely have
to scroll both
horizontally and vertically
to find their desired content.
However, with text
-
only
enlargement and a fluid layout users can generally enlarge text up to 200% without ill effects.
At
least three functional areas (Top navigation, All categories page and My d
ashboard) have
resizable text issues that cause important page elements to be obscured when the font is
enlarged. These issues have yet to be addressed as part of the ongoing remediation of Sakai
OAE and may occur in newly developed features/widgets.

User

Control of Updates

Users should always have a mechanism to control the

frequency of updates, including stopping
updates entirely.
If the focus changes due to system activity or update then the user may
become disoriented and be forced to relocate their
place in a feature/widget
. Numerous Sakai
OAE features including: recent activity feed, infinite scrolling, and the suggested content
carousel have update accessibility issues for users of adaptive technology. These issues have yet
to be addressed as part
of the ongoing remediation of Sakai OAE and may occur in newly
developed features/widgets.

Error identification and Prevention

Form controls have become ubiquitous and are
a crucial

part of interacting with webpages.
An
important part of interacting with
Web forms is validation. Therefore, error identification and
prevention is a requirement for ease of use. Unfortunately, some Sakai OAE features/widgets
display i
ncorrect or inadequate error messages. In particular the
My account

functional area has
numer
ous error identification issues
.
In addition, required form controls are not indicated to
users before validation in most features/widgets. These issues prevent users with disabilities
from either easily interacting with form control or accomplishing thei
r desired outcome (change
password). These issues have yet to be addressed as part of the ongoing remediation of Sakai
OAE and may occur in newly developed features/widgets.

Con
textual

Meaning

Visual context has become an important part of experience the
Web today. Unfortunately,
users with many different types of disabilities cannot access or comprehend these visual
contexts. Therefore, equivalent alternative means
must be provided

to provide these users with
this context. The most egregious issue with c
ontextual meaning in Sakai OAE is the use of
numbers as a counter. These numbers (e.g, in the left hand navigation) are meant to identify
the number of items in a functional area. In most cases
,

these numbers exist as solitary pieces
of content only
visu
ally associate
d

with
their context
. When information (e.g., number) is
related to a link or button, it should be explicitly associated with its related context.

Some improvements have been made in Sakai OAE releases leading up to v1.1, are currently in
rem
ediation or have been fixed in future releases. These include:



Color is the Only Means of Conveying Read/Unread Messages

(Fixed 1.3.0)



Top navigation inbox link does not make sense to non
-
visual users (Fixed 1.2.0)

However,
some
newly developed features/widgets exhibit
these same
contextual meaning
issues.

Miscellaneous Issues

Multiple functional accessibility issues not addressed by the WCAG 2.0 success criteria
were
discovered,
which may
hinder the use of Sakai OAE for users
with disabilities
.
One
issue

is that
there is no way to delete multiple items. This issue was specifically found in the My contacts
and My memberships functional areas. Without this ability it, removing unwanted items could
cause repetitive stress issues
for people with certain types of disabilities.
Another issue is that
many of the interactions in Sakai OAE are new and novel (e.g., tiered autosuggest search box
and the content authoring feature), yet there is no contextual
help documentation for these o
r
any part of Sakai OAE. The creation of feature specific and accessibility related help
documentation would greatly improve user experience.
These issues have yet to be addressed
as part of the ongoing remediation of Sakai OAE and may occur in newly devel
oped
features/widgets.

Detailed Recommendations

The Sakai Accessibility Working Group
recommends

that all UI developers be required to have
a basic
level of understanding in accessibility evaluation, design and development techniques

(
e.g.
labeling form
co
ntrols, images, unique and meaningful link text, etc.)
. Without this requirement,

a cycle of constant
remediation can become
commonplace
.

This cycle of remediation is expensive,
slows down releases

and puts increased pressure on other groups to groups to
identify accessibility issues
.

This can lead to
accessibility issues slipping past the quality assurance processes
without remediation.

The Sakai

community should consider

the needs of

all users and also

for the legal obligations of the adopting
institutions.

If a

basic level of understanding in accessibility evaluation, design and development
techniques

are not known to the UI developer
s, training should be provided to increase their level of
accessibili
ty awareness and knowledge through the use of videos, coding samples, checklists and style
guides
.

An
overall plan
and style guide
for
the
consistent provision of semantic affordances provided to
users of
adaptive technology should be developed and provid
ed to all d
e
velopers
.

D
evelopers can
implement

this guide and related resources when coding the user interface and quality assurance testers should
refer to this
guide to test for consistent application of the semantic affordances.

This

documentation
will

focus

on solutions, accessible design and development patterns that designers and developers can
reuse or compar
e against their own solutions.
The semantic affordance style guide will help new and
redesign Sakai
OAE
features/widgets to

be built up from we
ll designed, reusable c
omponents that will
be

built and validated for usability and accessibility.
This will help insure that newly developed widgets
and features meet base accessibility guidelines and will reduce the amount of functional evaluation time
needed to verify accessibility.


In parallel with development
of the semantic affordance style guide
,
a developer checklist and
testing

protocols for newly developed widgets and functional areas
should be created.
The developer checklist
will distill the W
CAG 2.0 success criteria and ATAG into simple coding requirements which can be
supplemented by semantic affordance style guide.
The testing protocols will help

automatically validate
(where possible)
the accessibility of widgets and features
against the
developers checklist and style
guide

themselves.
As part of these protocols, the Sakai Acc
essibility Working group recommend
s
developers use the
Deque Worldspace Fire
E
yes

tool
(
http://www.d
eque.com/products/worldspace
-
fireeyes
) to evaluate code for accessibility issues
. Fire
E
yes is the most comprehensive and accurate
freely available accessibility testing tool.

Currently, the accessibility testing is
completed

separately
from other quality a
ssurance
(QA) testing.
Incorporating

all or part of the accessibility testing into the quality a
ssurance testing
will help to

identify
accessibility issues before a version release.
Accessibility experts will help quality assurance testers
incorporate the
semantic affordances style
guide
with current testing protocols
to test for consistent
application of the semantic affordances
.

The
Sakai OAE
QA group has begun to use
testPAD

(
https://ontestpad.com
)
for QA testing.
Using the same tools,

criteria and testing scripts as the QA group
will help avoid duplication of
effort while creating new walkthrough scripts. In addition, all results from
both QA and accessibility testing would be together in one place. The only draw
back would be the
accessibility of the testPAD Web interface. After some initial testing, further recommendations can be
made.

New widgets and features will be included and changes to the current interface will be made with each
new
version of Sakai OAE.
Currently, the Sakai
A
ccessibility
W
orking
G
roup ha
s no idea of what changes
have occurred,
what new features are slated to be added

and what features will be redesign or removed

until they are included in a release build and development work has begun.
T
his process requires
remediation of accessibility issues only after they have been
developed
. These remediated issues
generally will not be included in the current release, but in a
future

release. This leads to an extended
period of time that a user with

a disability must overcome or work around the issue. However, if
accessibility experts
are i
ncluded

in the design
and requirements gathering
phase
s
, they will be able to
point out
potential accessibility c
onsiderations so they may be addressed

during the prototyping phase
of development. This would help to avoid the need for remediation.

Finally, an accessibility
roadmap
should be developed and if needed accessible
alternatives
or
workarounds for problematic features. This roadmap will make
the general public
aware of the
accessibility status and remediation efforts

for Sakai OAE
.

For many non
-
technically oriented
professionals, the navigation of the JIRA system is very complex and confusing. The accessibility
road
map
will be written in simp
le language with limited details covering the targeted accessibility issues
for each release. This roadmap would be modeled after the main Sakai OAE roadmap.

Evaluation Limitations

Due to the accelerated release schedule of Sakai OAE (roughly 3 month
s
)
and
finite resources
, multiple
functional areas and widgets were not evaluated. Therefore, the accessibility review was not a
complete review. In total, the Sakai Accessibility Working Group identified 32 functional areas as high
priority for review. 12 of t
hese high priority areas were reviewed between February 23rd and May 10
th
.
Any functional areas that were missed during the Sakai OAE v1.1 review or that will receive significant
modifications in subsequent releases will be slated for review in the
evalua
tion
.

Do to issues inherent in the technology used for testing, specifically the fragmentation of features
supported by assistive technology

and software bugs
, the recommendations for remediation may not
prevent users of assistive technology from experienc
ing accessibility problems while using Sakai OAE.
Numerous different types of assistive technology were used during the accessibility evaluation including
multiple screen reading software programs and voice recognition. The recommendations are based on
ex
isting Web and Web accessibility guidelines an
d

standards and should be implemented even if
unsupported by current versions of assistive technology.

During the accessibility
evaluation,

concurrent remediation of
multiple documented
accessibility issues

(filed JIRAs) was
started or
completed. These remediated issues may not be reflected in the results of
the evaluation. The Sakai Accessibility Working
G
roup made a concerted effort to note issues currently
in remediation or
issues that have
have

been resolved in future releases. All issues will be added as
JIRAs before then next accessibility review commences and the evaluation wiki pages will be updated to
reflect the current accessibility status of Sakai OAE.



Appendix: WCAG 2.0 Success Crite
ria

The complete results and methods are publically available on the Sakai Accessibility Working Group’s
confluence wiki pages under the heading Sakai OAE v1.1 Accessibility review
(
https://confluence.sakaiproject.org/display/2ACC/Sakai+OAE+v1.1+Accessibility+Review
). Any
questions or concerns about this report can be addressed to the Sakai Accessibility Working Group
(email:
accessibility@collab.sakaiproject.org
)
.

WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

1.1.1 Non
-
text Content:

(Level A)

All non
-
text content that is presented
to the user has a text alternative that
serves the equivalent purpose, except
for the situations listed below.

Fail



Top
Navigation



Explore page



Search All



My Dashboard



My messages



My library



My Contacts



My memberships



My profile



My account



Content Authoring



All categories



Major



Major/Minor



Major/Minor



Major



Major/Minor



Major/Minor



Major/Minor



Major/Minor



Major



Major



Major



Minor



No



No



No



No



No



No



No



No



No



No



No



No

1.2.1 Audio
-
only and Video
-
only
(Prerecorded):

(Level A)

For prerecorded audio
-
only and
prerecorded video
-
only media

a
n
alternative for
time
-
based media is
provided that presents equivalent
information for

prerecorded audio
-
only
content or e
ither an alternative for
time
-
based media or an audio track is
provided that presents equivalent
information for prerecorded video
-
only
content.

N/A




1.2.2 Captions (Prerecorded):

(Level A)

Captions are provided for all
prerecorded audio content in
synchronized media, except when the
media is a media alternative for text
and is cle
arly labeled as such.


N/A




WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

1.2.3 Audio Description or Media
Alternative (Prerecorded):

(Level A)

An alternative for time
-
based media or
audio description of the prerecorded
video
content is provided for
synchronized media, except when the
media is a media alternative for text
and is clearly labeled as such.

N/A




1.2.4 Captions (Live):
(Level AA)

Captions are provided for all live audio
content in synchronized media.

N/A




1.2.5 Audio Description (Prerecorded):
(Level AA)

Audio description is provided for all
prerecorde
d video content in
synchronized media.

N/A




1.3.1 Info and Relationships:

(Level A)

Information, structure, and
relationships conveyed through
presentation can
be programmatically
determined or are available in text.


Fail



My profile



Top Navigation



Explore page



All Categories



Category Sub
category pages



Search All



My Dashboard



My
messages



My
library



My Contacts



My memberships



Content Authoring



Critical/Major



Major



Major/Minor



Major/Minor



Major



Major/Minor



Major



Major



Major



Major



Major



Major



No



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial

1.3.2 Meaningful Sequence:

(Level A)

When the sequence in which content is
presented affects its meaning, a correct
reading sequence can be
programmatically determined.




Pass




WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

1.3.3 Sensory Characteristics:

(Level A)

Instructions provided for understanding
and operating content do not rely solely
on sensory characteristics of
components such as shape, size, visual
location, orientation, or sound.

Pass




1.4.1 Use of Color:

(Level A)

Color is not used as the only visual
means of conveying
information,
indicating an action, prompting a
response, or distinguishing a visual
element

Fail



My messages



Major



Yes

1.4.2 Audio Control:

(Level A)


If any audio on a Web
page plays
automatically for more than 3 seconds,
either a mechanism is available to
pause or stop the audio, or a
mechanism is available to control audio
volume independently from the overall
system volume level

N/A




1.4.3 Contrast (Minimum):

(Level AA)

The visual presentation of text and
images of text has a contrast ratio of at
least 4.5:1

Fail



Explore page



Category Subcategory pages



My
Dashboard



My messages



My library



My Contacts



Top Navigation



Sign in widget



All Categories



Search
All



My memberships



Major/Minor



Major/Minor



Major/Minor



Major/Minor



Major/Minor



Major/Minor



Minor



Minor



Minor



Minor



Minor



No



No



No



No



No



No



No



No



No



No



No

1.4.4 Resize text:

(Level AA)

Except for captions and images of text,
text can be resized without assistive
technology up to 200 percent without
loss of content or functionality.


Fail



Top Navigation



All categories



My Dashboard



My messages



Minor



Minor



Minor



Minor



No



No



No



No

WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

1.4.5 Images of Text:
(Level AA)

If the technologies being used can
achieve the visual presentation, text is
used to convey information rather than
images of text

Pass




2.1.1 Keyboard:

(Level A)

All functionality of the content is
operable through a keyboard interface
without requiring specific timings for
individual keystrokes, except where the
underlying function requires input that
depends on the path of the user's
movement and not just the endpoints.

Fail



Content Authoring



My
contacts



My memberships



Top Navigation



Explore page



Category Subcategory pages



Search All



My Dashboard



My library



My Contacts



My memberships



My profile



Blocker



Critical



Critical



Major



Major



Major



Major



Major



Major



Major



Major



Major



No



No



No



No



No



No



No



No



No



No



No



No

2.1.2 No Keyboard Trap:

(Level A)

If keyboard focus can be moved

to a
component of the page using a
keyboard interface, then focus can be
moved away from that component
using only a keyboard interface, and, if
it requires more than unmodified arrow
or tab keys or other standard exit
methods, the user is advised of the
method for moving focus away.

Fail



My Dashboard



Explore page



Blocker



Critical



No



No

2.2.1 Timing Adjustable:

(Level A)

For each time li
mit that is set by the
content: t
he
user is allowed to turn off
the time li
mit before encountering it; or
the
user is allowed to adjust the time
limit before encountering it at least ten
times the length of the default setting;
or

t
he user is warned before time
expires and given at least 20
seconds to
extend the time limit with a simple
action, and the user is allowed to
extend the time limit at least ten times

N/A




WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

2.2.2 Pause, Stop, Hide:

(Level A)

For moving, blinking, scrolling, or auto
-
updating information, all of the
following are true:
for
any moving,
blinking or scrolling information that (1)
starts automatically, (2) lasts more than
five seconds, and (3) is presented in
parallel with other con
tent, there is a
mechanism for the user to pause, stop,
or hide it unless the movement,
blinking, or scrolling is part of an
acti
vity where it is essential; and for

any
auto
-
updating information that (1)
starts automatically and (2) is
presented in paralle
l with other
content, there is a mechanism for the
user to pause, stop, or hide it or to
control the frequency of the update
unless the auto
-
updating is part of an
activity where it is essential.

Fail



My Dashboard



Explore page



Search All



Blocker
/Major



No



No



No

2.3.1 Three Flashes or Below
Threshold:

(Level A)

Web pages do not contain anything
that flashes more than three times in
any one second

period, or the flash is
below the general flash and red flash
thresholds.

N/A




2.4.1 Bypass Blocks:

(Level A)

A mechanism is available to bypass
blocks of content that are
repeated on
multiple Web pages
.






Fail



Top Navigation



Explore page



All Categories



Category Sub
category pages



Search All



My Dashboard



My
messages



My
library



My Contacts



My memberships



Content Authoring



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major




Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial

WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

2.4.2 Page Titled:

(Level A)

Web pages have titles that describe
topic

or purpose
.

Fail



Category Subcategory pages



My Dashboard



My messages



My library



My Contacts



My memberships



My profile



My account



Content Authoring



Major



Major



Major



Major



Major



Major



Major



Major



Major



No



No



No



No



No



No



No



No



No

2.4.3 Focus Order:

(Level A)

If a Web page can be navigated
sequentially and the navigation
sequences affect meaning or operation,
focusable components receive focus in
an or
der that preserves meaning and
operability.

Fail



My account



Explore page



My messages



My library



My memberships



My Contacts



Major



Minor



Minor



Minor



Minor



Minor



No



No



No



No



No



No

2.4.4 Link Purpose (In Context):

(Level
A)

The purpose of each link can be
determined from the link text alone or
from the link text together with its
programmatically determined link
context, except where the purpose of
the link would be ambiguous to user
s in
general.

Fail



Top Navigation



Explore page



Category Subcategory pages



Search

All



My Dashboard



My Contacts



My memberships



Critical



Major



Major



Major



Major



Major



Major



Yes



Partial



Partial



Partial



Partial



Partial



Partial

2.4.5 Multiple Ways:
(Level AA)

More than one way is available to
locate a Web page within a set of Web
pages except where the Web Page is
the result of, or a step in, a process
.






Pass




WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

2.4.6 Headings and Labels:
(Level AA)

Headings and labels describe topic or
purpose.

Fail



Top Navigation



Explore page



All Categories



Category Sub
category
pages



Search All



My Dashboard



My
messages



My
library



My Contacts



My memberships



Content Authoring



My account



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial

2.4.7 Focus Visible:

(Level AA)

Any keyboard operable user interface
has a mode of operation where the
keyboard focus indicator is visible.

Fail



Top Navigation



Explore page



Search All



My contacts



My account



Content Authoring



Category Subcategory pages



My library



My memberships



Major



Major/Minor



Major



Major/Minor



Major



Major



Minor



Minor



Minor



No



No



No



No



No



No



No



No



No

3.1.1 Language of Page:

(Level A)

The default human language of each
Web page can be programmatically
determined.

Pass




3.1.2 Language of Parts:
(Level AA)

The human language of each passage or
phrase in the content can be
programmatically determined except
for proper names, technical terms,
words of inde
terminate language, and
words or phrases that have become
part of the vernacular of the
immediately surrounding text.

Pass




3.2.1 On Focus:

(Level A)

When any component
receives focus, it
does not initiate a change of context.

Pass




WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

3.2.2 On Input:

(Level A)

Changing the setting of any user
interface component does not
automatically cause a change of context
unless the user has been advised of the
behavior before using the component.

Fail



My contacts



Major



No

3.2.3 Consistent Navigation:
(Level AA)

Navigational mechanisms that are
repeated on multiple Web pages within
a set of Web pages occur in the same
relative order each

time they are
repeated, unless a change is initiated by
the user.

Fail



My messages



My library



My membership



Major



Major



Major



Yes



Yes



Yes

3.2.4 Consistent Identification:
(Level
AA)

Components that have the same
functionality within a set of Web pages
are identified consistently.

Fail



My messages



Major



No

3.3.1
Error Identification:

(Level A)

If an input error is automatically
detected, the item that is in error is
identified and the error is described to
the user in text.

Fail



Sign in widget



My account



Major



Major



No



No

3.3.2 Labels or Instructions:

(Level A)

Labels or instructions are provided
when content requires user input.







Fail



Top Navigation



Explore page



Search All



My Dashboard



My messages



My
library



My Contacts



My memberships



My profile



My account



Content Authoring



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial

WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

3.3.3 Error Suggestion:
(Level AA)

If an input error is automatically
detected and suggestions for correction
are known, then the suggestions are
provided to the user, unless it wou
ld
jeopardize the security or purpose of
the content.

Pass




3.3.4 Error Prevention (Legal, Financial,
Data):
(Level AA)

For Web pages that cause legal
commitments or financial t
ransactions
for the user to occur, that modify or
delete user
-
controllable data in data
storage systems, or that submit user
test responses, at least one of the
following is true: Submissions are
reversible, data entered by the user is
checked for input er
rors and the user is
provided an opportunity to correct
them, a mechanism is available for
reviewing, confirming, and correcting
information before finalizing the
submission

Pass




3.3.5 Help:
(Level AAA)

Context
-
sensitive help is available.









Fail



Sign in
widget



Explore page



All categories



Category Subcategory

pages



Search All



My Dashboard



My library



My Contacts



My memberships



My

profile



Content Authoring



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



No



No



No



No



No



No



No



No



No



No

WCAG 2.0 Success Criterion

Pass/Fail
N/A

Affected

Functional Areas

Severity Level

Resolved in
subsequent

release

(Yes/No
/Partial
)

4.1.1 Parsing:

(Level A)

In content implemented using markup
languages, elements have complete
start and end tags, elements are nested
according to their specifications,
elements do not contain duplicate
attributes, and any IDs are unique,
except where the specifications allow
the
se features.


Pass




4.1.2 Name, Role, Value:

(Level A)

For all user interface components
(including but not limited to: form
elements, links and components
generated by scripts), the
name and
role can be programmatically
determined; states, properties, and
values that can be set by the user can
be programmatically set; and
notification of changes to these items is
available to user agents, including
assistive technologies.

Fail



Top Nav
igation



Explore page



All Categories



Category Sub
category pages



Search All



My Dashboard



My
messages



My
library



My Contacts



My memberships



Content Authoring



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major



Major




Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial



Partial