Photo of Jamie & Lion

The personal site of Jamie Knight, a slightly autistic web developer, speaker and mountain biker who is never seen far from his plush sidekick Lion. View the Archive

Definition of Done for Accessibility Tasks.

If you have ever worked on an agile team, you have probably come across the term “Definition of Done”.

The DoD as it is known, is the checklist which standardises the requirements before work is considered finished. You can read more about the definition of done on

A DoD for a11y.

I’m currently building a small virtual team which will focus on accessibility related tasks. The tasks are pretty wide ranging. For example, conducting design reviews, resolving bugs, or helping to prototype a complex UI widget. That sort of thing.

Part of building this team has been to build the process; and today I have been thinking about what makes a great DoD for accessibility tasks.

A prototype DoD for a11y.

This is my prototype DoD so far:

  1. Peer Review
  2. Testing
  3. Documentation
  4. Labels and Component Check

1: Peer Review

I think all good DoD’s should start with a “peer review”. That is, a code review or for the task to have been paired on. The purpose of a peer review or pairing is to introduce a second set of eyes to the code. This helps to reduce future bugs, and also allows for knowledge transfer.

2: Testing

The BBC Accessibility team has a recommended test matrix. In an ideal; world, we would suggest that all tickets are tested in the entire matrix. However, as the team is operating on these tickets is doing so on a voluntary bases i’m not convinced testing everything is going to be productive.

The aim of the testing is to provide confidence; knowing how much confidence is require is a complex topic… So my ideal accessibly DoD includes testing, but I am not sure how much yet. If you have a suggestion, or a model for this, please let me know in the comments.

3: Documentation

This will not apply to all types of tickets, but I think for many tickets documentation is a requirement. In short, if no documentation is being produced, I think there needs to be a good reason as to why.

Like testing, documentation is a bit of a slippery slope. You can easily do too little or too much. At this stage I am thinking that each ticket type should have the following documentation requirements before it is considered “done”:

4: Labels & Component Check

One of the outcomes required for the process is to enhance the understanding of the type and quantity of accessibility tasks coming through the team. So an explicit step in the DoD to check that labels and component attributes have been correctly set is a cheap investment to aid future statistical analysis.

What am I missing?

Thats some of my thinking so far; It’s early days the proposal above is very rough. What would you suggest? Do you have an a11y element in your DoD? Let me know in the comments, or via twitter (@jamieknight) and email

Published: 1 September 2014 | Categories: Permalink

A physical controller for Hue smart lights

TL:DR I’m using an Xbox controller to control my smart light. Code is on GitHub.


I received a set of Phillips Hue smart lights for my birthday. I really like them. I have been working on a proper review; but this post is about my first hue hack. Physical controls.


App controlled lighting is awesome. When I want it, I have complete control of my lighting. But I don’t always want complete control. Often I want something simple and more importantly something fast.

For those situations I wanted a physical controller. Something where I can turn on a preset or an individual lamp easily.

I wanted something physical for ease of use. I want to use this thing to check for monsters at midnight when unlocking my phone is too fiddly and slow.

Hue has a product for this (the Hue Tap) but its pricey and I wanted too build something more expressive.

Why the Xbox controller

I picked the Xbox controller for 3 reasons:

  1. I have one
  2. I knew of a node library to control it (thanks Andrew)
  3. it has enough buttons to do fun stuff.

How does it work

When I press a button on the controller, it trigger an event in a node.js app.

The node apps then sends the preprogrammed command to the hue bridge which in turn controls the lights. Source code can be found at:

The Controls.

The control scheme is has 4 areas. Presets, Individual controls and group light switch.

The dpad maps to presets:

The coloured buttons and shoulder pads are used to control individual lights.

And finally, group light switch.

Usage Patterns

I’m using the presents most, but the Individual light control comes in handy when I want to just light my bed or desk etc.

Where Next

I have a few ideas too extend and enhance the system.

  1. Wireless controller – I need to buy the little wireless dongle so I can go cable free.
  2. More than lights – I also want to control TV volume and fan from the same controller. This can be done via an OS X system event API and a wireless mains switch.
  3. Multiple rooms

final words

If you have any question feel free to email me, or leave a comment. If you spot a bug please open an issue in GitHub.

Published: 25 August 2014 | Categories: , Permalink

The Future of the Mac Mini

I like the Mac Mini, its small, fast and quiet. Just what I want for under the telly.

It could be smaller though. It could also be faster, but I don’t think its likely to get both smaller and faster.


The Mac Mini uses laptop chips; the same chips as the retina MacBook Pro for the one I have. However, those chips are not the most power sipping, running 44w or so.

If Apple updates the Mac mini today to the equivalent haswell chip it would get ~16% faster and the graphics power would double perhaps triple.

This would be nice. If it stayed upgradable1 that would be perfect. I already game on my Mac mini, and better graphics would be nice.


What if Apple swapped to using the processors from the MacBook Air? At 15w these chips run much cooler and sip power. The Mac Mini could get far smaller.

I don’t think it could get quite as small as the current Apple TV. But Pehaps it could get much thinner or change shape into a small round puck.

This would be a totally integrated device. Like the inside of the MacBook Air, everything soldered down except maybe the storage.

If it cost £339-399 with the same guts as the 11” MacBook Air, that would be compelling.

Final words

I have been drafting this post for a while. Since i started Apple accidentally released a reference to a Mid 2014 Mac Mini on the tech support website. So hopefully something is coming soon.

I like the Mac Mini and I hope it has a long and exciting future, hopefully the next step of its evolution will be with us soon.

1 My 2012 2.6ghz Mac Mini has two drives (256gb SSD, 1tb HDD) and 16gb of RAM. Both were easy to install, and could be further expanded in the future.

Published: 30 July 2014 | Categories: , Permalink

Older Articles