Good morning. My name is Gregory Hughes and I'm a software engineer at Apple. I'm really excited to be able to have the opportunity to speak to you this morning, and today you're going to learn how to use universal design principles to make your applications better and more accessible. And I want to start off by explaining what I mean by universal design. And to illustrate universal design, I thought I would use something we're all very familiar with, and that's the kitchen stove.

I'm sure most of you use the kitchen stove on a very regular basis and most people accept the design of the kitchen stove. However, it turns out that the design is actually quite poor, specifically the row of knobs across the front and the back of the stove that are used to control the burners.

Each of these knobs requires a small icon or a localized label to tell a user what burner that knob controls. Now I know with this design I personally have accidentally turned on the wrong burner and this is a really, really common mistake. And in the case of a stove, it can actually be a very dangerous mistake.

Now, users make this mistake for a number of reasons. Perhaps, they're in a hurry preparing dinner for guests, maybe water is boiling over or maybe the user just forgot their glasses in another room. However, with this design, there are also a number of accessibility concerns. For someone with low vision, it can be very difficult to read these labels. For someone who is completely blind, it could be really difficult to figure out which knob controls which burner. And for someone with a cognitive impairment, it can be very difficult to create the mental mapping between this row of knobs and the matrix of burners.

So if we design the stove more universally, if we think about the needs of all users including users with disabilities, we can end up making a much better stove. If we rearrange the knobs so that they're in the same order as the burners, the stove becomes much easier to use for everyone.

You no longer need to read a label. You instantly know which knob controls which burner. It's now also more accessible because someone with low vision doesn't need to read a label and someone who is blind is able to feel the knobs and know exactly which burner that knob controls.

And equally, someone with a cognitive impairment will have a much easier time making the mental mapping between the arrangement of knobs and the arrangement of burners. In the case of the stove, an equally valid design choice may be to rearrange the burners so that they're in the same order as the knobs. So we see here by applying some universal design principles, by looking at the needs of all of our users, we end up making a much more usable, much better product for everyone that everyone will have an easier time using and will reduce user frustrations.

And so that's what I would like to talk to you today about: How you can apply these universal design principles to your software to make it better for everyone so that your users experience less frustrations in using your software. At the same time, you'll be making your software more accessible.

And to talk about that today, I have three main focus areas. First are the end users. Now with all design, you want to start thinking about the needs and requirements of your users. Oftentimes universal design goes hand in hand with the term user-centric design, and that's design focused on the users.

So, not only do you want to think about the users here but you want to think about how and where and potentially when they'll be using your software and under what circumstances. So then, I'd like to speak about some of the accessible technologies that Apple has built into a number of our products, and these help highlight how accessible technologies also make products better. These universal design features are making the operating system and our portable products better for everyone. And last, I want to talk about how you the developers specifically can make enhancements to your applications to make them better for everyone and more universally designed.

So, let's start with the users. And to get an idea of what we're talking about here, I want to start off with some statistics. In the U.S., 10 million people have a vision impairment, 31 million people have hearing impairment, and 12 million people have a learning disability. And what that means is that 1 in 5 people in the U.S. has a disability.

That's 50 million people. Let's stop and think about that for a minute, 50 million people have a disability in the U.S. alone. By making yourself more universally designed and more accessible, you're going to be able to have a much easier time reaching this huge percentage of the population. At the same time, you can have an easier time entering government and education markets, which often require your software to be accessible. So there's a huge potential audience here especially world-- including worldwide.

So to look at this audience, there are 4 main areas we want to think about. First are visual considerations, and these are considerations pertaining to vision. These are considerations for users that perhaps have reduced visual acuity, users that are maybe color blind, or users that are completely blind, and even users that just don't have their glasses with them.

Then, we have auditory considerations and these are considerations for users with hearing impairments. Users who can't hear as well as the average user or users who can only hear out of one ear. This also includes users who are completely deaf. And then we have physical considerations, and these are considerations for users that have a hard time physically interacting with a computer. These are users who have a difficult time using the keyboard or mouse. And then cognitive considerations, and these are consideration for how a user thinks when they're using your software.

This potentially includes users with learning disabilities and other users who just need an easier time using your software who would benefit from a more simplified interface. So we've now talked a little bit about the users and let's look at some of the technologies that Apple has to address these users.

First is a very common universal design feature that you'll see a lot this week, and that's Fullscreen Zoom. This is used a lot in presentations to highlight a specific portion of the screen, but it's also indispensable for a user with a vision impairment because they're able to zoom in on various areas and enlarge the font. There's a number of these large font solutions across the OS.

In Address Book, you can make phone numbers large print. This is great if you're sending a fax from across the room but also wonderful for someone with lower vision. In the Dock, the Icon Magnification helps someone with low vision see the icons, but it's also really aesthetically pleasing.

So we see how these features make the software more usable and at the same time have the benefit of making it more accessible. We have closed captioning in iTunes, iPods, iPads, iPhones and pretty much everywhere we have video. This is obviously really important for someone who is deaf, but it's also crucial if you're trying to watch something while on the gym or in the airport and you don't have the ability to wear headphones. Or maybe you want to want a documentary in the library and you can't listen to the sound there. So, again another universal design feature that's helping everyone but is also increasing the accessibility of video.

There's also-- we have talking iPods, and this originally was designed for people who are completely blind so they could interact with the iPod and listen to their music, navigate through the menus, but it's also very usable for someone who's driving a car perhaps and they just want to scroll through their music without diverting their visual attention.

And now this interface turned out to be so usable and so successful it's the only interface on the new iPod shuffle. So it's a great, great universal design feature that turned out to be the only method of interaction in newer hardware. And then we have VoiceOver, and VoiceOver is Apple's screen reading solution.

And what this does is it converts all of the wonderful graphical information on the screen into spoken information so that someone who is blind can use a computer. And VoiceOver now has been shipping for 5 years and it's installed on millions of Macs. And this number is really important because the VoiceOver now is installed on more computers than all of the other screen reading solutions combined. And that's really important because it shows what a huge role Apple is playing in the assistive technology market and how important it is for you as well to make your software accessible.

VoiceOver now is also shipping on the iPhone as of the iPhone 3GS and on the iPad, along with a slew of other universal design features that help all users, and most of these you don't even think about. For example, Pinch to Zoom in Safari. We all use that but it's a great feature for someone who is visually impaired. And so if we think about some more of these features that we can add, we end up making better software.

So with that, I'd like to look at how we can make better software. What you can do to your applications and how to look at your applications to find these areas that could be improved. So remember, we have these 4 groups: visual, auditory, physical, and cognitive. And when looking at these 4 groups, we have 4 categories that we want to think of. The first is perceivable. Can the user perceive the information you're trying to present? Do they have the ability to get the information? This is generally going to deal with the output of your application.

Is your software operable? Does the user have the ability to operate your software? Can they provide the input that you're expecting? Is it understandable? Does the user understand what you're trying to present to them? Do they understand the UI? And is it robust? Can your software adapt to the very needs of users in the varying situations where they might use your software? And so, this ends up forming a nice grid and you can actually use this as a report card to go through and look at your software, and it helps you to think about all these different areas and we would love you to get A+ marks across this report card. And if that's the case, you end up having much better, much more well-designed software for all of your users. And throughout this talk, I'm going to use a small sample app to highlight some of these universal design features. This is a portfolio watcher.

It just watches some stock, shows me how they're doing and gives me my day's change, and we'll see how we can improve this through universal design. So first let's look at these-- the visual considerations, and generally these considerations fall into the perceivable category because we're dealing with vision. Can a user perceive the output that you're trying to present? And to start, let's look at iTunes. Now, iTunes has a wonderful high resolution interface and in the iTunes Store, they're displaying a lot of content.

And you can resize the iTunes window and resize even smaller. And as it turns out, this is really important for accessibility because a very common technique for someone with low vision is to increase the screen resolution. And so having your window be resizable, usable at all resolutions, it makes your application much more accessible, and at the same time it gives all users the ability to control the window size and it lets the user select what window size works best for them.

So generally, we recommend that your applications be usable down to at least 1024x768. And the important distinction here is that it's usable at that low resolution. We really want you to develop beautiful high resolution interfaces to take advantage of our large displays, but you always want to keep in mind that some users are using these lower resolutions, so you want all of your features to be accessible at these resolutions. This is also going to help when presenting your software.

You never know when you're going to connect to a projector that's 800x600 and you don't want to be caught in a situation where you're giving an important presentation only to have half of your features inaccessible. And that's going to help pretty much anyone who is reducing their resolution to help release-- relieve eye strain. I know a lot of travelers do this often when working on an airplane.

It's really, really simple to do right at Interface Builder. You just want to set the minimum size of your window to the absolute minimum size usable and then check your application. And sometimes this might involve adding some scroll areas here or there, but in general it's really, really easy. So next, I want to look at Mail.

And here's a screenshot of Mail and I'm sure it's very difficult to see especially if you're sitting in the back. And if I blur it a little bit, it helps us to simulate what it might look like to someone with a vision impairment, and now it becomes absolutely impossible to read.

Now, Mail has a wonderful feature that's used by everyone and it makes Mail better. You can adjust all of the font sizes in Mail. And now this is great for any user or someone who's presenting Mail and showing off the interface, and you can make that even bigger, which is wonderful for someone with low vision. And so this is a really, really important feature that makes the software much more robust.

And you'll see this across a number of Apple applications. In the System Preferences, you can often change the font from the Key Content area. Sorry, in the Application Preferences. And the Key Content area is the important distinction here. You want to look at your application and figure out where users spends most of their time visually, and concentrate your attention on trying to make the fonts in that area larger or at least user sizeable. So in an application like Safari, the Key Content area is easy to determine, it's the large web area, but sometimes it's a bit more difficult.

So this obviously is going to help users with low vision. It's going to help elderly users, users who don't have their glasses with them, and again, it's going to help you if you're ever presenting your software so that users, so that people in the audience are able to see what you're presenting to them.

It's really, really simple to do. What I recommend is creating one bottleneck in your application. And at this point I do want to mention that all of the source code I'll be presenting here is available on the WWDC web site so you don't need to worry about copying any of it down.

So if you create a single point in your application, you can always ask that method for the current user to find font size. And here is just a quick example, I'm asking System-- or asking my Application Preferences for the font size, then bounds checking it and returning the user desired font size.

To use it is easy. I'm going to ask NSFont for a system font of that size and I'll get back a valid NSFont that matches all of my other system fonts, and then I can just apply that to any NSTextField really, really easily. Now, the other very common area for adjusting fonts is in tables, and tables are slightly more involved but still not that difficult at all.

For a table, remember we have columns and so we need to iterate through the columns and set the font for each data cell. So we go through that here. Going through the columns we grab the data cell and then set the font for the data cell. And then the only slightly tricky part is now that we're increasing the font, we need to change the row height. So in order to do that, we can ask NSLayoutManager for the line height for our font and then set the row height appropriately.

So as you can see a bit more involved, but still really, really simple and not much work at all to make the fonts in your application resizeable. Next, I want to look at another interface that probably looks very common to you. So let's just demonstrate-- this interface is showing two stocks and showing their day's change. However, for a user who is color blind, this interface doesn't convey any information.

I don't know if the stock is going up or going down. So the important thing here to keep in mind is never to use color alone to convey information. So using color is just fine and it's a really, really nice way to quickly convey information. Just don't use color alone. And oftentimes this is simple to solve.

In this case, if we add a plus and a minus sign, it now will tell a user who is color blind which stock is going up and which is going down. So the difference is very, very small here but it can make a world of difference to a lot of users who are using your software, and it's also going to make your software easier for everyone to use because it's now going to be quicker to glance at because we have color. And if you're looking at it more closely, you have the plus and the minus sign.

So all of that is really good for our low vision users, but what about users who can't see anything? How are they going to access this visual information? And as we saw with the case of color, we don't want to convey information with color alone. As it turns out, we don't want to convey information through vision alone. We want to be able to provide a spoken interface to every application. And on that front, all of the hard work is actually already done, and that's done through VoiceOver.

Remember, VoiceOver is the screen reader which is going to convert all the visual information into spoken information. But sometimes it requires a bit of work on your part to make your application more usable with VoiceOver, and that's really easy to do as well. In Interface Builder, you can set the Accessibility Description, Help Tag, Title Element and Linked Element without ever leaving IB. So it's really, really simple to do this for any of your controls that you have right in IB. As well, there's a programmatic way to do this.

You can use the convenience method set accessibility override, and here you can set the override for any of your standard controls for its Accessibility Description, Help Tag, Title, or Linked Element. Now, if you have a control that is your own custom view, you will need to do a bit more work for accessibility, and there's some great past talks on that. I encourage you to look at the WWDC 2009 talks, and they go into great depth on how to make your custom views more accessible and usable by VoiceOver. But for today, let's just look at the standard cases.

So, with that, I'd like to show you here how we can apply some of these techniques to our sample application. So, here we have Xcode. If I run my app here, it's the sample app that I showed you in the slides and we can look at this window and I can't resize it much more than this, which can be frustrating for any user who just wants to make the window small and push it to the side of the screen. So let's go into IB and fix that.

So here we have our window. If we bring up the inspector for the window size-- but here it's already set to a minimum size of 900 and I know that my application can be resized all the way down to 450. So really, really simple to change, we switch and look at that now.

I can resize the window quite a bit smaller. So a small change has a significant impact for the accessibility and usability of your application. Next, let's take a look at fonts. So here, if I look at my Preference window, I see that someone has already left me a convenient place for a font slider.

So if we bring up the library here and add a slider, you see that the designer has also already decided that we want a font size between 8 and 40, and this range will probably be dependent on your application but 8 and 40 is probably a pretty decent range to be considering.

And I want to make sure that my bounds of the slider are the same so I'm going to set those to 8 and 40. And I also want it to update continuously. And now for my slider, I'm going to bind it to my delegate and I'm going to bind it to the font size property.

So if we save that, we can now go into Xcode and look at the methods that we need to control the font size. So let's bring up the delegate, and I'm sure if you have ever worked with bindings, you know the first thing you'd really want to do is make sure you add your getter and setter for the property. So let's add those now. Here we have first a very simple setter. We're going to take in a value, and first because we never want to be dealing with fractions of a point, we're going to round the value.

Then store in Preferences, Synchronize Preferences, and update the fonts for my application. The getter is equally simple. I load the value from Preferences then bounds check it against my lower bounds. You may also want to check your upper bounds and then again return a rounded value because I want to just doubly check that I'm never dealing with fractions of a point. So now we need to get a system font, an NSFont of that size.

So that as well is really easy. We're going to get the font size that the user wanted and ask for a system font of that size. And now we have our method here which is going to do the updating for tables. Remember, we're going to iterate over the columns, apply the font to each data cell and then lastly update the row height. So a bit more involved for tables but still really, really easily. And now the last thing we need is the actual method to do the work.

And if we add this method here, we see for our three text labels, we're going to set the new font and then for our two tables, we're going to set the font of those tables. And now to make sure I always have the current user preference, I want to make sure to call updateFonts in my awakeFromNib method. So at the end of awakeFromNib, I'm going to call update fonts and let's run the application.

So now if I bring up our Preferences here, I have this font slider and I can adjust all of the fonts of my application. And you'll see here we have a slight problem. Our two labels are being cut off. And let's go and fix that.

So in our updateFonts method, we just need to also update the layout of our UI, so I'm going to call self updateLayout.

And now that's going to call a method that I've already written. The method is a bit long but the logic is really, really simple. It's all just basic math, laying out the controls appropriately within my view, and when possible, letting Interface Builder take advantage of all the springs and structs that I've already defined. So let's take another quick look.

So now when I adjust my font, all of my controls layout and resize appropriately, and I think that's probably a good font size. If I'm demoing my software, now it's much easier for everyone to read. So next I spoke about VoiceOver and how we want to make sure our application has this audible output. Now, there're some really great tutorials on how to use VoiceOver built right into the Mac.

When you turn on VoiceOver, you'll have the opportunity to learn how to use VoiceOver. But for today, I just want to let you listen to what a VoiceOver user might hear when navigating our application.

Unknown: VoiceOver on portfolio watcher window, portfolio watcher edit text, add a symbol.

So here we hear add a symbol, and if I go through the UI we'll hear each element.

Unknown: Edit text, blank button.

So here we see one problem, VoiceOver just says button. VoiceOver doesn't have enough information to tell the user what this button does. And so we'll have to go in and add a description for that button. Let's continue along.

Unknown: Table one row selected, symbol AAPL, name Apple.

So it works fine for the table and you'll find that it works fine for any standard Cocoa control, especially the text controls. It's generally your custom controls or any graphical elements that you'll need to do a little bit of work for.

Unknown: Days change zero dollars and 82 cents, zero button.

And so again we have this other button. And those aren't accessible because they have images and we're just going to need to provide a quick description for those buttons. Let's do that now.

Unknown: VoiceOver off.

If we're going to Interface Builder, I can have the description for one button right here. Right here under accessibility description, I'm going to call this the Fullscreen button. And just to show how to do it, I'll label the other button programmatically. So if we switch back to Xcode and I have a small two line method here to update the other button, we see we're going to grab a localized string because just like our UI it needs to be localized.

Our strings for VoiceOver need to be localized, and I'll set that string as the description for the button cell. I also need to make sure to call this method when I awakeFromNib just like I wanted to update my fonts. So at the end of my awakeFromNib I'm going to call self updateAccessibility and let's take a quick look at that.

Unknown: VoiceOver on portfolio watcher window, portfo-- add stock button.

So here we now have a description for this button.

Unknown: Take date fullscreen button.

And a description for our other button. So you can see adding this basic accessibility really doesn't take that long at all. It just involves going through your application, finding the areas that need a little bit of work and updating them so that VoiceOver has something to speak for all of your controls.

Unknown: VoiceOver off.

So next I want to talk about audio considerations, and again these are considerations for users with hearing impairments, users who are perhaps using mono audio or users who are completely deaf. And to start out, I want to show a quick video.

Now, I'm willing to bet you can't get a whole lot of information from this video because the only means of output is audio and I muted the video.

So you can see how difficult it would be for someone who's working in a library or someone who's deaf to access that video. Let's take another look at it.

And now actually, this demonstration worked out pretty well because there was actually supposed to be audio with that second video, and it shows how important it is to make sure that everything you're presenting is accessible.

You were still able to get the information out of that video by reading the subtitles. So the important part of audio is to make sure that you're never presenting information using audio alone, that you always have some other method of conveying that same piece of information. You also want to be aware that some users are using mono audio, that they don't have the ability to hear the two stereo channels. And also some users have sensitivity or can't hear higher or lower frequencies, so you may want to consider having assignable user sounds in your preferences. This is going to be up to your application and, you know, how much flexibility you have with what sounds are being played.

So if we want to make sure that we always have this visual counterpart to our audio, how do you do it? Well, one very convenient and easy way is to use NSBeep. Now with NSBeep, there's a systemwide preference that someone who's hard of hearing can set so that when NSBeep is called, the screen will flash. It looks a bit like this.

So, whenever you're going to use something where there's going to be sound, if you want to play the system sound but also provide that visual feedback, always use NSBeep because it's going to give you that accessibility for free for those users who have the need for the screen flash. But there are a lot of other ways that you can display visual information to go along with your sounds. One of the really great ways is to use your Dock Icon.

For example, I've been demonstrating the stock watching application. If my application, if my stock portfolio dropped a huge percent in a small amount of time, I might play a sound to warn the user, or I could also change my Dock Icon to be red, and it provides that visual feedback that goes along with the sound.

Equally, I may change the Icon to green if the portfolio is doing well, again, providing visual feedback to go along with the sound. And so we see here the importance of providing these multiple methods of information output to a user and it ends up making the application much more usable for everyone, much nicer to use and it helps convey all the information you want to convey in an easy manner. So, changing your Dock Icon is really, really simple. In two lines of code given the PNG, you can set your Dock Icon to pretty much whatever you would like. But there's a lot more that can be done with the Dock Icon.

You can badge your Icon, and this is a really convenient way and very common way of conveying visual-- conveying new information. For example when you get a new mail message, you hear the new mail message sound but it's combined with the updating of your unread message count in the Dock. So it's that visual and audible component to the information that mail is trying to present to you.

And you can also bounce your Dock Icon, and this is a great way to visually tell a user that your application wants attention while it's in the background. Maybe this goes along with an error sound or some other method of informing the user that you want-- you want attention.

So, I'd like to quickly show you now how we can apply some of those techniques and making our application more accessible to users who are hard of hearing.

So here, if I go to my non-audible feedback section, first, I'm going to add a method that calls NSBeep. You can see how simple it is. We'll just take a look at what that looks and sounds like on a real system.

Next, we have how to change the Dock Icon and this method looks a bit long but it's really, really simple. All I'm doing is a bit of string coercion here. My method takes in a number between negative 1 and positive 1 and then displays an icon that varies from red to blue to green to represent the status of my portfolio.

So here, I take in the number. I then find the appropriate image name for that number and then these two lines here do all the actual work of setting on your Dock Icon. So, really, really simple here to change your Dock Icon. Obviously now, I want to call this method from somewhere. In my application, I have a timer going to update my portfolio. So, let me call that from my refresh method. At the end of this method here, I'll call self setDockIcon and I'll set to change percent sometimes 5.

So, in dealing with nonaudible feedback, you also want to think about your application and what you might be able to do to make your audible feedback have some visual component to it, and this could be different for every application. This could be some animation that you provide to go along with your audible feedback. And just as a quick example of an animation that I chose, here I have a message that's going to flash my window different colors.

And so, I'm going to cycle through a few colors and flash the window that color. And so, just as playing sounds can sometimes be annoying, some of these animations could be annoying to a lot of your users and in that case, you want to make sure to put them behind User Preferences, and that will allow a user who needs this option to enable it where appropriate.

And the last one I want to show was bouncing a Dock Icon. And because my application used to be in the background to bounce my Dock Icon, I'm going to call this on a delayed performSelector, and then there's just one line to bounce my Dock Icon. So, let's take a look at this now.

So we see here, first my Dock Icon is green because my portfolio is positive. If I now bring up the Preferences, we can see what NSBeep looks and sounds like. So, a great way to provide that visual feedback automatically and it lets the user select which sound they would like to hear, which sound works best for them.

It can also bounce the Dock Icon, so a great way of telling the user visually that your application would like attention. And lastly, just a quick very, very rough animation, I can flash my window different colors. And this might just tell the user different statuses or different things have changed.

So there we have it, some very, very simple changes that you can make that will greatly help users with hearing impairments. So now, let's talk about users with physical impairments, the physical considerations that we need to think about with our software. These generally fall into the operable category. Can a user operate your software? Can they provide you with the input that you expect? And when thinking about this category, we want to look at the keyboard and the mouse.

These are generally the two primary methods of providing input on Mac OS X. And we want to think about users who perhaps don't have the keyboard or can't use the keyboard, or maybe users that don't have the fine motor ability to use the mouse. Meekly, we want to consider users that don't have either one and are potentially using speech input to control your applications. As it turns out, there's a lot of permutations here of the various input methods that could be used, but they're all very simple to address. And you can address them by providing full keyboard access to your application.

This is really simple to test. Just try to use your application without using the mouse. Try to make sure that you can use all the features and all the functionality with just the keyboard. That you can navigate to every single control and use every single control. Some of the tactics here to do this are to provide keyboard shortcuts for the menu items so that you can quickly activate various options in your app.

So here, this is a great case where this universal design feature is going to strongly or greatly help your super-- or your power users who want quick keyboard access to the very commonly used features and at the same time, you're going to be helping users with physical disabilities.

Now, two of the common areas that I've often seen where full keyboard access is difficult are in reordering lists and doing dragging and dropping. Now, reordering lists is common-- are commonly done by dragging one row and dropping it in a new position, so somewhat difficult to do with the keyboard. It turns out the solution is quite simple.

If you just add a moveUp and a moveDown command to your Edit menu, you now allow a user to use their keyboard to reorder any list that you have in your application. And equally here, you'll see I've also bound this to a keystroke, so the menu item has a keyboard shortcut which is also going to help my power users.

Now, for dragging and dropping, for example, an application that requires that-- where a user is going to move a photo from one album-- photo album to another, instead of dragging it from that album and dropping it in a different album, I could simply cut it from one album and paste it in another.

So, by fully implementing cut, copy and paste, we help get around the keyboard navigation problems of drag and drop interfaces. So, this is really, really easy to do and it's implementing NSPasteboard protocol and there's some great documentation online on how to do this for your application. So, I also said you want to be able to make sure that you can get to all of the controls in your application that you can Tab through your application.

And when doing this, you want to make sure to enable full keyboard access, and what this is is a feature in the operating system to allow a user to navigate the entire operating system using the keyboard alone. And in keyboard-- in system preferences under keyboard preferences, you'll see here at the bottom, there's a small checkbox to enable full keyboard access to all controls. You want to try this on when testing your application to make sure that you can Tab to everything. So, let's take a look at that now.

So, first let's take a look at reordering lists. I'm going to go into Interface Builder. I've already implemented the drag and drop portion of reordering my list and now, I need to add the keyboard access to it. So, I'm going to bring up my Edit menu here and add two items, moveUp and moveDown--

-- and also provide them with keyboard shortcuts. Now, I've already written the prototypes for these methods so I can go ahead and bind them.

And now, let's look at the work that needs to be done in Xcode. So, I've already written all of the methods, as I said, for the actual dragging and dropping implementation and the key here is that it's already architected well. Here's my method that's dealing with the actual drop. I mutate the numbers a bit to get them in the format I expect and then call my one method that does all of the work.

The method is called Moves Dock at Index to Index. So, this is the method that's actually going to do the work of reordering the rows. And given this architecture, adding a moveUp and moveDown command is really, really simple. So we see here, moveUp is two lines. We get the currently selected index in the table and then we move that index to the currently selected index minus 1.

MoveDown is just as simple, we're just going to add 1. So here, we see with 4 lines of code, we're going to have greatly increased the keyboard navigation of our application. So, if I now Tab to my table, I can Arrow to my table and then with Command and the Arrow keys, I can move one of these stocks up or down in my list.

So you see, this is going to be great for yours-- your power users who want to get it on to your application quickly, but it's also going to be the way that users with physical disabilities are going to be interacting with your software, and so you want to make sure it's all usable with just the keyboard. And so now, we want to look at Tab navigation.

We want to make sure we can get to all of the controls, and so the first thing here as I said, we want to go to System Preferences and make sure turn on full keyboard access. So, we're going to turn on all controls here. And now, I'm going to Tab through my application and just make sure I can get to everything.

So, at the Add a Symbol field, I move to Add a Stock button to the table and then to this Fullscreen button at the bottom. So, I can get to everything just fine here. If I open up the Preferences, I'm starting here at the Tab control at the top.

Pressing Tab moves me to the font slider, and Tab again moves me to the negative color and then backwards to the positive color. And so, something is wrong there with the automatic Tab ordering that was created by the operating system. So, you always want to check your application, make sure the Tab ordering is correct. As it turns out actually, in this case, I had to play some really evil tricks to get the Tab ordering to be incorrect. So almost always, it will be fine. But let me show you how you would fix it if it were incorrect.

If I go into Interface Builder here and I look at my Preferences window, what I want to do is first start at the window, and I'm going to set the initial key to this initialFirstResponder to my Tab control and then for the Tab control, I want to set the initial first responder to the slider.

From there, the slider's next key view will be the positive color. And from the positive color, the next key view will be the negative color. From the negative color, you want to make sure to make a full loop, so we're going to go back up to the Tab control and set the next key view to the Tab control. So, let's take a quick look now.

So if I press Tab, I move from the button at the top to the slider-- oh, and I didn't do something right, so let's take another look here. So from the slider, we want to go to the positive color. Positive color to the negative color and then negative color back up to the top.

So, if I press Tab from the button at the top, I go to the slider, then the positive color then to negative color and back up. So really, really simple to test, really simple to fix and it greatly improves the usability of your application, again for those power users who want to get around quickly and for users who don't have the ability to use the mouse.

As well as I said, this is going to solve all of your input issues. For users who are using speech input, they're going to now be able to use Apple scripts to control your application because it's fully navigable with the keyboard. So, we solved a lot of problems with a very small amount of work.

So, next are cognitive considerations, and these are considerations for how user thinks when they're using your software. These are considerations for users that perhaps have disabilities like learning disabilities or maybe even just the type of user. For example, a student is probably going to use your software in a different way than a teacher is going to use your software. And so, to look at cognitive considerations, I want to look at iPhoto.

Now, iPhoto has a great interface and it's a very, very powerful photo management application. And it also allows me to edit my photos. Now this interface can actually be a bit confusing and overwhelming to some users because all you want to do is just browse and look at your photos. And iPhoto has done a great job solving this.

To do it, iPhoto has implemented Fullscreen mode and in Fullscreen view, you can go through your album, look at all of your photos and eliminate all of the distractions. Now, while in this mode, you can also get to a lot of the UI. You can get to the photo chooser by going up to the top or the edit controls at the bottom. So, this is really important because iPhoto is presenting only the controls that the user needs when they need them. So, it's eliminating distractions and also hiding unnecessary UI when it doesn't-- the user doesn't need the UI.

As it turns out here, entering this Fullscreen mode is super, super easy. You can do it with one line of code. Given an NSView, you just say enterFullScreen mode, provide it a screen and there are few options that you can pass in as well. So, really, really easy to implement this, a very, very powerful way of making your application easier, simpler to use for everyone, but also more accessible to those users with cognitive impairments.

Now, I said iPhoto is hiding some UI and hiding UI is really, really important here. We want to make sure not to overwhelm a user with UI, so you want to think about what options are more advanced, what options are less used and see if you can come up with ways to hide those options. A great tactic is to use a contextual menu. So perhaps you have a lot of buttons and 50 percent of those are used by 2 percent of your users. Consider putting those options in a contextual menu instead.

Another great way of hiding more complicated or less used UI is to use menu alternates. What this is, it's something we've probably all seen. When you open up any menu in OS X, you can press the Option key and it will display different menu items if they're provided.

For example here in the Apple menu, if I press the Option key, a few of the items change. Now, that was actually pretty difficult to notice in the slide, but if we look at the two menus, we see that about this Mac change the system profiler. The system profiler is something that most users never ever need but we still provide that option.

So, the important thing here is that you don't really want to take away features from the user but at the same time, you want to balance that with making your UI simple, making all of the features used by 90 percent of the users available all the time and maybe hiding those other features that are used by only 10 percent of your users. So the-- to add a menu alternate, you simply add a new menu item and in Interface Builder say this is an alternate menu item.

What that means is that that menu item will replace the previous menu item when a user presses the option, so really, really simple to do and very powerful nice way of hiding more advanced or less used UI. So, let's take a look now at how to do Fullscreen mode in our application. So, if we switch over here to the application, I have a place for the Fullscreen method.

So we see again very, very simple method. I already have the button in the UI. The buttons are already wired up, so let's take a look at it.

So we see here now, we've able to enter Fullscreen mode really, really easily, eliminated all distractions for user. But the same time here now, we see how a lot of our work today has come together. We're now able to make the font sizes larger. We're using color and the plus and the minus sign to convey information quickly and to all users.

And we've generally made our software more usable, more robust, and easier for everyone. We've just made the software better because there are more options to the user. Someone now could set this on a second monitor and just watch their portfolio all day long rather than having to search through windows to look at it.

So, you're going to make your applications much better and much more liked by our users because you're going to eliminate some of those frustrations that users often run into when using your application. So, in summary today, we've talked about 4 groups. We've talked about visual considerations, auditory considerations, physical considerations, and cognitive considerations. For visual considerations, remember, we want to keep in mind the resolution. We want our application to be usable at lower resolutions.

Whee possible-- we want the font size of the key content area to be adjustable by the end user. We're going to make sure we keep in mind colors that are used in our application, never use color alone to convey information. And lastly, we want to make sure that the application is accessible to VoiceOver by implementing the NSAccessibility protocol on any custom classes and providing information in Interface Builder for any standard Cocoa controls. For auditory considerations, you want to make sure to always provide information through multiple channels. Never provide information through audio alone. Always be aware that some users are using mono audio, and you also want to make sure that any videos that you're presenting have closed captions.

For physical considerations, you want to consider users that aren't using the keyboard and mouse. And to do this, you want to make sure that your application is fully navigable using the keyboard alone. Some tricks here are to use many alternates and always make-- sorry, many shortcuts, and always make sure that any mouse actions have a keyboard alternate. Lastly, we have cognitive considerations.

These are considerations again how a user is going to think when using your software. You want to make your UI as simple as possible. And to do this, you can use things like Fullscreen mode. You want to also consider hiding more advanced to less used UI by either contextual menus or making menu alternates.

So, if you have more questions, there's a ton of information available regarding both accessibility and universal design. I strongly recommend that you join the Accessibility Mailing List. It's a very well trafficked and friendly mailing list for any of your questions. There's also great documentation in which you can get to via the WWDC website. And Apple also has a really wonderful accessibility web page which talks about accessibility and accessible interfaces in all of our products. It also provides you with links to any documentation that you may need.

We also had some related sessions this week. There's a session on iPhone accessibility tomorrow afternoon and we have two labs. Now, both of these labs are the ones that says OS X and ones for the iPhone. The entire team of engineers that work on accessibility will be at both of these labs. So, if you have any questions, whether they're iPhone or OS X, please come to the labs and talk to any one of us. We'll all be there. And I'd like to thank you very much for your time this morning. It's been a pleasure talking to you.