Improving the Accessibility of FootPrints 

At Northwestern IT, we use an IT Service Management system called BMC Footprints 

which is very dated and needs a lot of improvement to be called “accessible.” I used it as 
an example of bad design for our very first assignment. 

U.S. Government Section 508 Compliance/Visually 

Impaired Enhancement 
To its credit, FootPrints has a setting internally that enables the software to be used more 
effectively with screen readers. Unfortunately, there is a lot more that it could be doing. 
As far as I was able to tell (even looking at the source code for the main pages of the 
site), all that changed was the format of menus in the application. They went from this: 

To this: 

(Notably, one of these menu options, Appearance, doesn’t exist and goes nowhere when 
clicked. The accessibility of the site to screen readers might be increased, but if this 
option adds fake menu options, how helpful is it?) 

Improving the Homepage 

The first page of this document is the homepage of FootPrints after logging in and it 
leaves much to be desired. there are many changes that could be made pretty quickly to 
fix up some of the accessibility problems both for typical users and for differently-abled 
users. 

WAI-ARIA Attributes 
WAI-ARIA​ is a standard put forward by the World Wide Web Consortium that serves to 
define the ways that Web 2.0 applications should be designed to enable accessible 
access. One subset of this standard is ​WAI-ARIA in HTML​, which allows developers to 
specify what the role (meaning “purpose” in this context) of an element on the page is. 
For example, an HTML ​<button>​element may be used to take a user to a new page (in 
which case its role is ​link​
) or it may be used to submit a form (in which case its role is 
button​ ). 

FootPrints has none of these attributes. For the sections outlined in red on the 
screenshot of the FootPrints homepage on the first page, this is how the code could have 
been rewritten to be more accessible: 

1. <div id=”Search” role=”search”>...</div> 

2. <nav id=”Nav” class=”DocumentWidth”>...</nav> 
(the ​role​attribute is implied here – by default, all ​nav​elements have role 
navigation​ ) 
3. <button role=”button”>...</button> 

There are numerous other problems with the way that these are designed, chiefly that 
they use a lot of HTML tables to do their formatting123456, which can wreak havoc on the 
site’s load time and accessibility. Almost all tables can be replaced with ​Semantic 
elements​ (like I did with the ​div​⇒ ​nav​conversion above) or with CSS display styles78.  

(Perhaps most disturbingly, each row in the main table of information on the homepage is 
itself a table. As in, every row in the table represents a table ​nested within​ another table. 
It’s a semantic nightmare.) 

Switching Workspaces 
FootPrints allows for different IT teams to create silos for themselves so that they can 
each manage their incoming requests through workflows specific to the department. For 
many years, for example, Northwestern IT could transfer issues that Weinberg professors 
were having with their computers into the Weinberg IT workspace so that Weinberg 
could organize the issue as they saw fit and respond to the customer in whatever format 
their protocol dictated, even if it was different from ours. 

Some users of FootPrints have access to multiple workspaces. Managers at 

Northwestern IT, for example, have access to the main Northwestern IT Service Desk 
1
​https://html.com/tables/#About_Table-Based_Layout 
2
​https://webmasters.stackexchange.com/questions/6036/why-arent-we-supposed-to-use-table-in-a-design/6037 
3
​https://www.lifewire.com/dont-use-tables-for-layout-3468941 
4
​http://daviddickball.uk/2011/04/why-you-shouldnt-use-tables-for-layout-ever/ 
5
​https://www.smashingmagazine.com/2009/04/from-table-hell-to-div-hell/ 
6
​https://www.hotdesign.com/seybold/everything.html 
7
​https://www.w3schools.com/css/css3_flexbox.asp 
8
​https://www.w3schools.com/css/css_grid.asp 
workspace in addition to the IT Survey workspace, which houses all of the responses to 
the brief “How did we do?” survey that is sent out with all of our emails. 

Figuring out how to switch to this workspace for the first time is next to impossible. Here 
is the toggle that allows a user to switch workspaces: 

It appears at the top right of the homepage and appears to simply be a line of text. It’s 
small and unassuming, and even though the mouse pointer turns into the “grabbing 
hand” when hovered over, this element otherwise has no properties that indicate that it is 
interactive at all. When clicked, it transforms into this: 

To be more accessible, the element should appear as a dropdown list at all times. As far 
as I can tell, in its current form, this element is also inaccessible via keyboard navigation; 
no matter how many times you press “Tab,” you will never select this toggle (or if you do, 
it’s impossible to tell you’ve done it). 

Letting this element remain an unstyled dropdown (like the one on the second 
screenshot above) would allow the user to know when they’ve selected it if they’re using 
keyboard navigation and it would also be a better indicator to all users that it is the 
correct control to use to change workspaces, not just to display the current workspace. 

Request Flag Indicators 

Requests in FootPrints can be flagged based on properties that they have so that certain 
types of tickets are visible in a list at-a-glance. For example, deans, department chairs, 
and administrators at Northwestern are likely to have more time-sensitive requests than 
others, so their tickets get a special property when they’re received: ​VIP Status: DDCA​. 
We have an indicator for these requests on our homepage so they’re easy to pick out of 
a list. Requests with “VIP Status: DDCA” display with a purple bar underneath them 
(visible on the first page for issues 963313, 963637, and 963665). 

The issue with these flags is that ​there is absolutely no indicator of what they mean​, for 
any kind of user. All it is is a purple bar with no tooltip information and no information for 
screen readers. In the code, all that applies to these issues is ​border-bottom: 5px 
purple​which wouldn’t change the way that a screen reader parses the text at all. 

I would propose a solution more like this (when hovered over): 

<​
style​> 
*
​​{ 
​
font-family​ : s​ans-serif​ ; 
} 
 
.
​ticket​{ 
​
display​ : i​nline-flex​ ; 
​
flex-direction​ : c​olumn​ ; 
} 
 
.
​ticket​. ​indicator​{ 
​
height​ : ​
5px​ ; 
​
position​ : r​elative​ ; 
} 
 
.
​ddca​{ 
​
background-color​ : #​993399​ ; 
} 
 
.
​ticket:hover​. ​tooltip​{ 
​
opacity​ : 1​.0​; 
​
pointer-events​ : ​
auto​ ; 
} 
 
.
​indicator​. ​tooltip​{ 
​
pointer-events​ : ​
none​ ; 
​
opacity​ : 0​;
​ 
​
transition​ : opacity ​ 0.18s​​ ease-out​; 
​
top​: 1
​50%​ ; 
​
left​: ​0;
​ 
​
padding​ : 5​px​; 
​
background-color​ : r​gba​ (0
​​, ​
0,​ 0
​​
, 0
​.8​); 
​
border-radius​ : ​
5px​; 
​
position​ : a​bsolute​ ; 
​
white-space​ : n​owrap​; 
​
color​: ​white​ ; 
​
font​: ​0.8em​s ​ans-serif​​ bold​ ; 
} 
</​
style​ > 
<​
div​c​lass​ =​
"ticket"​ > 
<
​​
span​c ​lass​ ="
​ticket-number"​​ aria-describedby​ ="
​tooltip-963313"​
> 
963313 
</​span​> 
<
​​
span​t ​itle​ ="
​VIP Status: DDCA"​​ class​
=​
"indicator ddca"​​id​
="
​flag-963313"​
> 
​
<d
​iv​​class​ ="​tooltip"​r ​ole​ =​
"tooltip"​​ id​
="
​tooltip-963313"​> 
This ticket was submitted by a DDCA. 
​
</​
div​> 
<
​/​span​> 
</​
div​> 
This solution allows for all users to easily glean what the indicator flag on a ticket actually 
means​. Screen readers will use the ​aria-describedby​attribute to find relevant 
information to present about the indicator and other users can hover over the indicator to 
see the tooltip that explains its meaning. 

Links to Other Information 

The links on the homepage are only differentiated from other text by color, which doesn’t 
appear well in grayscale9. One simple CSS style change fixes the links on the whole site: 

<​
style​> 
a
​​{ 
​
text-decoration​
: u
​nderline !
​important​
; 
} 
</​
style​> 

To make the text slightly more legible, we can also add the following: 

<​
style​> 
a
​​{ 
​
text-decoration​
: u
​nderline !
​important​
; 
​
line-height​
: 1
​.2​
; 
} 
</​
style​> 

9
​https://axesslab.com/practical-accessibility-improvements/ 
  

Keyboard Navigation 
In addition to the issues with keyboard navigation listed in ​Switching Workspaces​, there 
is a lot to be desired for the site as a whole. There is no “Skip to content” control that can 
jump to the site’s contents, and correspondingly, there is no element that effectively 
describes the main content of the site. The information on the homepage should be 
wrapped in ​<main>...</main>​to indicate this. 

It appears that, like many sites, FootPrints has removed the focus indicator from almost 
every element on the page. When navigating through the document by keyboard, very 
few elements stand out as they gain focus, and some of the ones that do change change 
so imperceptibly as to be useless. 

To fix this, a simple change can be made: 

html​> ​
body.ext-webkit​*
​:
​focus​{ 
o
​utline-color​
: r
​gb​
(7
​7​
, 1
​44​
, ​
254​
) ​
!important​
; 
o
​utline-offset​
: -
​2px​
; 
o
​utline-style​
: a
​uto​!
​important​
; 
o
​utline-width​
: 5
​px​!
​important​
; 
} 

 
Then, the outlines appear again when navigating the site using the keyboard.