How to enable all controls on Safari and Chrome under Mavricks.

By default, OS X does not reveal all on screen controls to the keyboard. This means that without changing setting the tab key wont select links on webapges. Tha tab key will only select buttons and forms etc.

To enable all controls:

1. Open “System Preferences”
2. Enter “keyboard shortcut” into the search box in the top left and press return
3. At the bottom of the screen, select “All controls”

Then:

1. Open Safari
2. Open Preferences in the Safari menu.
3. Open the “Advanced” tab
4. Tick the checkbox start “Press Tab to highlight…”

These instructions work for both Mavricks, and OS X Yosemite.

Published: 7 September 2014 | Categories: Mac , Development Permalink

2014 Mac Mini Review (1.4ghz, £339)

I’ve been a fan of the Mac Mini for a number of years. It’s my favourite Mac. After almost 2 years without an update, I was starting to worry that Apple were planning to drop it from the range

However, last week Apple awoke from its low end slumber with an all new Mac Mini and remarkably, a lower price as well.

Hardware

I can talk about the economics later. For now, let’s look at the hardware itself.

Starting from the outside, the new Mac Mini is a round black aluminium puck, 2.2” tall with a diameter of 6.6”. It’s a small Mac Pro by appearence.

The ports out back are mostly the same as the last generation. Like the Mac Pro, cooling is handled via a large central fan.

Going inside; The entry level model offers a 1.4ghz Dual Core i5 processor with HD 5600 graphics…. If that sounds familier, it’s because the Mac Mini shares it’s processor with the entry level MacBook Air and IMac.

The CPU is comparable to last years entry level 2.6ghz i5. The 1.4ghx clock speed is a little of a misnomer as this haswel based part can boost to 2.6ghz when needed.

The new CPU Is interesting in a number of ways. First, it has mich improved graphics, offering over twice the performance of outgoing the HD4000.

If also has good single threaded performance. With a geekbench score of 2467 its in the top 25% of all macs for single threaded performance.

This CPU also sips power. Apple states that the new Mac mini can run without a fan for most operation as it draws an iPad esque 2.5w of power while idle. When it really gets going, the Mac mini can draw up to 25w.

The CPU is interesting. But not that fast. The responsiveness if the system is mostly down to the new storage system called ‘Storage Bay’

Storage Bay

At its simplest, Storage bay is a slot in the back of the Mac mini where any 2.5” SATA drive can be inserted.

The base Mac Mini has the slot empty, but for £59 the Mac mini can be outfitted with a 1tb hard disk drive.

Storage Bay provides large file storage. The main operating system, boot files and most user files are stored on the integrated 32gb of flash storage for a fast responsive system.

This combo of an SSD core with large capacity HDD backend is impressive. It can be configured as either a fusion drive, or as two separate drives for manual file management.

Last years Mac Mini shipped with a dreadfully slow 5400rpm hard disk. The new Mac mini positively flies in comparison with read and write speed 5 times faster at 500mb/s apiece.

This added performance manages to come with a price reduction

£339

At £339 Apple have returned the Mac Mini to the original price when it was launched in 2004. The Mac mini is price competitive with iPads while offering 4-10x the performance.

For £339 you get the guts of a £700 laptop, with the ability too easily add RAM and storage capacity.

Going up the range, a higher performing i5 models starts at £499 and the top spec model costs £649 with quad core i7 CPU and 128GB of flash storage.

Final Thoughts

The new Mac mini is a return to form for Apple. Getting it out for less than £339 is a small wonder and we must assume Apple is dropping it’s normal margins to get there.

When considering a Mac, the question now is entirely about form factor. Performance at the entry level is now roughly equal whether your looking to a laptop, an ultrabook or a desktop.

If you don’t need portability or extreme performance and your already have a suitable display and mouse then the new Mac mini offers great value.

This article is a spoof review for a product i hope Apple would introduce… I wrote it as i was bored… and its fun to speculate!

Published: 6 September 2014 Permalink

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 scrumalliance.org)

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”:

• Bugs – a description of the cause of the bug, and a description of the fix and why it is believed to work. Possibly adding a label for later stats purposes. This documentation should be a comment on the JIRA ticket.
• Reviews – a review (design or code) should have at least a comment describing issues which were discussed and if possible any recommended actions (e.g., notes on tab order, or ARIA roles etc).
• UI Support Requests – if a ticket relates to advice on how to approach building some kind of UI pattern; then the documentation requirement is an overview of the methods considered and the reasoning behind which approach was chosen.

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: Development Permalink