-
Notifications
You must be signed in to change notification settings - Fork 4
SS12: Project Possibility rAdio Challenges
At the beginning of the project development, we tried to use CSS objects to represent the previous, play/pause, and next button along with ARIA roles to tell the screen reader what the element currently selected is. However, this development became difficult to access for users because it would require the user to be very specific on what element they are on. So, we changed this CSS button system to a semantic button element system where ARIA roles weren't needed because the title object allows the screen reader to tell the user what the button that is currently focused on. By doing this, we can have a simple button system that is accessible and that works well with the screen reader. We also used data URI, which gives you the ability to embed files inside of other files, so it only requires one HTTP request. This will give the player a small performance gain because requesting multiple HTTP requests would bug the player down, so using data URI optimizes the player.
<div class="clearfix">
<button class="" title="play previous song" id="previous"></button>
<button class="" title="play song" id="playPause"></button>
<button class="" title="pause song" id="pauseButton"></button>
<button class="" id="next" title="play next song"></button>
</div>
When developing the accessible music player, we needed to develop a way to easily manage the volume control. We found an open source slider control that allows the user to change the volume by simply moving the slider left to lower the volume or right to increase the volume. This can also be done when focused on by simply pressing the left or right arrows on the keyboard. The volume controls also works well with the screen reader so that the user can still hear each option they focus on. The below code is first the HTML code for the volume control console followed by the JavaScript for the increase in volume operation.
<section class="clearfix"><div id="volume_control" role="slider"><div id="slider-range-min"></div></div></section>
function volumeUp(){
var volume = $('#slider-range-min').slider("value");
if(volume >= MAX_VOLUME - VOLUME_STEP) {
$('#slider-range-min').slider("value", MAX_VOLUME); }
else{ $('#slider-range-min').slider("value", volume+VOLUME_STEP);
}
volumeSlide();
}
The use of shortcut keys and how to implement it to work well with the screen reader as very important in the project. It would allow the user to access the music player's primary components with ease. A primary challenge was developing which keys would be best to use for fast forwarding, rewinding, and playing/pausing a song. Another challenge was the way we conveyed the shortcut keys information to the screen reader which would tell the user the shortcut keys.
Below is the HTML code that allows the screen reader to tell the user what the shortcuts are.
<ul id="shortcuts" role="list" tabindex="3">
<li role="listitem" class="shortcut">?</li>
<li role="listitem">shortcut key listing - this menu</li>
</ul>
An Aria Role for the body tag was used so we can tell the screen reader that the music player is a web application and not a web document or article. This works well with the screen reader so that the user knows that the page is an application and informs the user.
<body role="application"></body>
For the CSS files, we implemented a CSS reset in the CSS file for the browser. There is also graceful degradation for older browsers so there is at least some accessibility for older browsers.
<!-- Prompt IE 6 users to install Chrome Frame. Remove this if you want to support IE 6. chromium.org/developers/how-tos/chrome-frame-getting-started -->
Not all users have up-to-date browsers so we used the Modernizr to fix this issue. It detects the availability of native implementations for newer browsers. It also tells the current browser if the feature is natively implemented or not.
<script src="js/libs/modernizr-2.0.6.min.js"></script>