22 I think it works - an accessible HTML5 video player

So, I think, other than a lot of cleaning up, I have an accessible video player.

Here is what it does (so far??):

• Can access all functions with a keyboard
• Screen reader announces everything  - Though not always beautifully. This depends on the browser's accessibility implementation, ARIA support and how the screen reader itself behaves. Having said that you can find all of the controls
• No keyboard trap
• Is still accessible while in fullscreen mode
• Has a synched second audio track that can explain what is happening in the video to people who can't see it
• Captions of course - I'm reasonably happy with the implementation of them
• The captions can be presented in different:
• sizes
• fonts
• colours
• coloured background
• transparent background 0% 25% 50% 75% 100%
• The captions can be moved around the video so captions doesn't obscure anything
• Works on modern HTML5 browsers
• I've left the interface fairly dry, at least so far, so the developers can implement their own designs with CSS
• This project doesn't include a fallback to a flash version, their are plenty (?) of flash video players available and fallback was discussed in the first stage of this project.

But I still have that niggling feeling that something is missing... maybe it's just the jitters. What do you think? If it does what I say it does, is that enough?

Student testing will begin soon. We have had a small problem this year, as other projects may have also found, TAFE teachers who were teaching in 2012 aren't necessarily still available in 2013. I am in the process of organising a meeting with some teachers who I am quite sure will be very interested in trying out this player with their class. 

Luckily there are still some excellent teachers left.

21 Making code more robust

Ok, so this week sees me looking at the code and thinking that it could be a lot neater, more general and apply to more situations.  I find when I begin programming a new project I make my code very specific. I 'talk' to my objects directly by name rather than the better method of being general by referring to parents and children of them.

Being direct makes it easier, in my mind anyway, to get results quickly. This is because I know where I am going wrong when things aren't working for the path to the object is clear, or, clearly wrong. But lately I can see the flaw in this in starting this way.

It's no good to be specific with code that you may use more than once on a page. I have to control more than one video player for example. Therefore I will have to speak generally to all video players which is much more efficient than speaking to one at a time.

I've made a start hopefully it makes it better.