You need to email a file or folder of files to someone, but the information is sensitive. These slightly geeky but easy to follow instructions will show you how to do it.
We’re going to compress the file(s) into a single zip file that’s encrypted by issuing one single command into the Terminal.
When you email the zipped file to a Mac or Windows user, all they will have to do is double click the file and enter the password you used to encrypt the file. Please after doing this do NOT put the password in the body of the email! Call them, text them, direct tweet them, just don’t put it in the email.
These notes were created by Donald Burr of Otaku No Podcast from otakunopodcast.com. Donald was the guest on episode #364 of the podcast. If you’d like to listen to the audio as you read along, click the link below:
When the iPhone first came out, people assumed that the blind wouldn’t be able to use it because it’s a touchscreen device with only 4 buttons. Apple proved them wrong. They have embraced accessibility in a BIG way. The iOS platform is the industry leader in mobile accessibility. Android, Windows Mobile, Blackberry, etc. don’t even come close. That’s why I’m a Mac/iOS user – my vision has fortunately remained stable, but I am always afraid that things might take a turn for the worse… but if they do I am ready for it
When talking accessibility, what are we talking about?
Primarily will be talking about accessibility for the visually impaired, because that’s the one that requires the most effort from developers. There are some considerations for other disabilities which I will briefly touch on later.
Basically each thingie on screen (button, text field, label, icon, etc.) has certain attributes that the Accessbility API’s need:
Is it an accessibility element? (Should VoiceOver be able to “see” it and recognize its existence?) (isAccessibilityElement)
What is it? (accessibilityLabeland accessibilityHint)
What are its traits? (accessibilityTraits)
Type of item (static text, button, image, adjustable control, etc.)
Is it clickable (can you interact with it)?
If it’s a selectable object, is it currently selected?
Does clicking on it start some sort of media playback (audio/video)?
If it’s an adjustable control, what is its current value? (accessibilityValue)
What are its on-screen coordinates? How big is it? (accessibilityFrame)
Here’s the good news: Apple makes it really easy to make your apps accessible. They provide a very rich set of tools and APIs that help with this. Which means you have absolutely positively NO excuse not to! In most cases, all it invokes is literally just a few extra lines of code, and poof, instant accessibility. In some cases, no coding is required at all.
Standard UI elements:
One of the great things about developing for iOS is Interface Builder – you can piece together your program’s UI by dragging and dropping from a large palette of UI widgets (text labels, buttons, sliders, etc.)
If you use these standard interface elements – guess what – the system automatically makes them accessible. Since Interface Builder knows what it is you’re putting on screen, it automatically fills in the necessary accessibility information.
Works best if your UI has obviously titled elements (i.e. a button titled “Play” that starts playing something).
Beware ambiguous labels (or controls that don’t have a label)!
Example: In the Otaku no Podcast app, in the Podcasts screen (first tab), there are entries for “Latest Audio Podcast” and “Latest Video Podcast.” Beside each is a “Play” button. It’s obvious to a sighted user what each Play button does; however, for a VoiceOver user, all they would hear if they tapped it is “Play” — play what??!
Example 2: In the Otaku no Podcast app, look at the Audio Player screen. The “play button” at the lower left uses the “play” graphic – no text label. In this case, since VoiceOver doesn’t have a text label to fall back on, it uses the filename of the image that the button is using. So you’ll hear something like “playbtn dot PNG” which is even worse!
In cases like this, we need to give iOS some more specific information.
In Xcode, highlight your UI element, then go to the Identity Inspector. There you will find a section on “Accessibility.”
“Enabled” – whether this item should respond to VoiceOver (You’ll almost always want this)
“Label” – What you want it to say (Example: for the “Audio Podcast -> Play” button I put “Play the latest audio podcast”; for the “play graphic” button I put “Play”)
“Hint” – This text is spoken after a short delay after the “label” is spoken. Useful to give the user additional information about this particular UI element. (Example: for the Refresh button, the button’s Label is “Refresh”, and its Hint is “Tap to check for new episodes…” – it gives the user some additional information if he/she is confused.)
“Traits” – Most of these options are very specialized, and you don’t want to go turning them on willy-nilly. Here are the important ones:
“Button” – is this a button?
“User interaction enabled” – can you “do” something with it? (I.e. tap a button, enter text into a text field, etc.)
You can still manipulate these values in code if you want (handy if e.g. you need to change your UI to respond to conditions when your app is running).
Sometimes the standard controls aren’t enough (you need more/different functionality); also sometimes you may use standard controls, but want to create and manipulate them in code (rather than using Interface Builder). In these cases, you will need to use code to set up all the necessary accessibility information.
Sometimes you may have an object that is subdivided into multiple sub-objects. You need to provide accessibility information for those sub-objects.
Example: the Convention Calendar tab in the Otaku no Podcast app. The entire calendar view is a single object; each individual day is a sub-object. Unfortunately this is one area where I still need work; it is completely inaccessible. I’m using an open source calendar library that isn’t yet accessible. I’m working with the developer to add accessibility to it. For an example of this done right, take a look at the iPhone’s Calendar app, in Month view.
In this case, we use a series of “accessibility containers.”
Each container provides a full set of accessibility information to the OS (description/label, value, hint, etc.), as well as the bounds (the physical location/dimensions of the area where this accessibility information is attached to).
These elements are stored in an array (an ordered collection of objects). You need to provide three pieces of information to the Accessibility API’s: the number of items in this array, a way of retrieving a given item #, and a way of testing if a given item is part of the array. (In 99% of the cases, these will be trivial one-liners.)
The iOS user interface is very dynamic. Things are moving around, morphing, swooping in and out, etc. Obviously blind users can’t see this. So iOS provides a way for developers to let the user know that “something happened” using VoiceOver.
There are three types of UI change notifications.
Screen changes: when your UI changes dramatically. Usually when a user moves into a different part of your app (navigates to a different screen). VoiceOver notifies the user with a tone, and it clears its caches and does other preparations to deal with a new set of accessibility data.
Layout changes: if some part of your UI changes, but the user hasn’t necessarily jumped to an entirely different part of your app. (Example: in the iTunes Store app, tapping on the price label ($0.99, etc.) next to a song changes it to a “Buy” button.) This notification tells VoiceOver to re-read the current state of all accessible items that are on-screen, and by doing this it figures out what has changed and informs the user of those changes.
Dynamic changes: if a part of your user interface is dealing with some dynamically changing information (state changes, data changes, etc.). This notification tells VoiceOver to read it out to the user. Example: in the Compass app, the compass value is constantly changing as the user moves his/her device in space. The Compass app sends a dynamic changes notification that tells VoiceOver to read out your current heading. Also useful for communicating any sort of significant status change in your app (“Loading complete,” “Connected to server,” etc.) You may only want to do this when a significant change in data has occurred, otherwise it can get real annoying. (for example, Compass only notifies when the compass value has changed by 5 degrees I believe.)
Your program can also tell where VoiceOver’s “focus” (the object that it’s dealing with) is, and when “focus” enters or leaves any given object.
A good use for this is, when a user is running VoiceOver, to present a more simplified UI to them, or otherwise change your UI to make it easier for VoiceOver users to interact with. Example: In the Photos app, the photo controls normally disappear after a few seconds to let you view the full image. This could be confusing to VoiceOver users; so if Photos detects that VoiceOver is in use, it prevents this auto-hiding behavior.
Naturally, like any other aspect of software development, you’ll want to test your accessibility code.
In the iOS simulator
The iOS Simulator has a built-in Accessibility Inspector. It displays all the accessibility data of any given object on screen (just click on it).
Access it by pressing the virtual Home button, launching the Settings app (you might have to swipe right to get there), tapping on General, then Accessibility, then turn on the Accessibility Inspector.
Unfortunately the accessibility inspector doesn’t support certain actions (notably the swipe gestures that let you change values of controls). Also it doesn’t really give you a “feel” for how an actual blind user would interact with your app. For this you really need to test on real hardware.
To enable accessibility – Settings -> General -> Accessibility -> VoiceOver -> turn it ON.
A shortcut is to set up the triple-click home button shortcut: Settings -> General -> Accessiblity -> Triple-click Home -> set it to VoiceOver
If you’re feeling really brave, you can enable Screen Curtain (completely turns off the screen, the closest thing to actually turning yourself into a blind person, and much more comfortable than a blindfold (or poking your eyes out)). Just activate VoiceOver then triple tap using three fingers. Repeat to turn off screen curtain.
Of course, doing your own testing is fine (and indeed is essential), but you really should be sending your app out to others to test.
If you localize your app, you also need to localize your VoiceOver prompts! (VoiceOver is available in 30 languages)
If you’re not localizing, you really ought to. The App Store is global, why shut out a potentially huge user base? Getting translators is easy and relatively inexpensive (try Craigslist).
Remember that localization doesn’t just mean translating words and letters; some countries have different ways of expressing date/time, currency, etc. iOS has code that helps in these conversions.
It’s always good to think outside the box.
With clever use of the accessibility tools, you can make things accessible that you wouldn’t think were possible.
A good example is the Stocks app. You’d think that there is no way that the graph at the bottom could be made accessible. You would be wrong.
They used accessibility areas to slice up the graph. For each slice, it tells you a representative date within that period, and the stock price for that date.
Less is more.
Keep your labels short. Users are going to be scrolling through these dozens of times.
If you want to provide additional information, use an accessibility hint. (That way users only get the additional information if they actually need it)
The more buttons, interactive elements, etc. on a screen, the harder it is for a VoiceOver user to navigate it.
If you really want the fancy UI, check to see if VoiceOver is in use; if it is then present a simplified UI.
Do not include an object’s type (“button,” “slider,” etc.) in its accessibility label. iOS will automatically read out the item’s type itself, so there’s no need for you to do so also (besides it makes your app look amateurish).
Remember that there are other disabilities besides blindness.
Physical Disabilities:Try not to make your UI teeny tiny. Of course this makes it more difficult for sighted people to use your app. But it becomes orders of magnitude worse when you throw physical disabilities into the mix(motor control difficulties, CP/MS, or people who use a head-mounted pointer, etc.) It also makes it harder for visually impaired (but not completely blind) users to see your app as well. IMHO this might be a compelling argument for a larger-screened iPhone (more space to spread out your UI in).
Deaf/Hard of Hearing: Some programs use sounds to indicate that something happened. It’s always a good idea to also include some sort of visual feedback as well, for those who are deaf/HOH.
Use standard controls (text entry fields, buttons, etc.) whenever possible. Not only is this good for usability (users know what an iOS text box/button/on-screen keyboard/etc. look like, they may not be able to instantly recognize your weird nonstandard UI); but using standard UI elements also gives you the highest level of compatibility with alternative input devices (head pointers,braille displays/keyboards, etc.). (Bad example of this is Mac OS Ken’s Secret Crypto Wonder Badge. Totally nonstandard keyboard.)
Apple’s Worldwide Developers Conference (WWDC) Conference info and registration: https://developer.apple.com/wwdc/ Videos of all conference sessions (2010 and 2011’s are up now, 2012’s will be up a few weeks after the conference is over): https://developer.apple.com/videos/ Note: conference videos are now available even to free developer program members! If you’re a serious developer, you need to go to WWDC. Unfortunately it tends to sell out pretty fast, so you’ve gotta be quick! They do make all conference videos available to paid developer program members; however, the real benefit of attending WWDC is that you get one-on-one “face time” (f you’ll pardon the pun) with real live Apple engineers who help you with your coding issues and help make your apps better.
CS193P Accessibility lecture:http://www.youtube.com/watch?v=5b0V6MltEnw Slides from this lecture: Accessibility.pdf In the past the CS193P course has had a lecture on accessibility; for some reason they didn’t in this year’s iteration of the course. Fortunately a video of the previous year’s accessibility lecture is still on YouTube. In this lecture the speaker gives a good overview of the accessibility API’s. He also does a demonstration in which he takes a completely inaccessible app (a bowling game), and in a few simple steps, makes it completely accessible and playable by even completely blind users.
“Smartphones Become Essential Accessories for the Blind”:http://www.youtube.com/watch?v=NQKtSR5Li1A This video was shown during the Stanford class above. It is a great overview of how the iPhone is really revolutionizing the way blind and visually impaired people interact and function in their daily lives.
VoiceOver article at Use Your Loaf: http://useyourloaf.com/blog/2012/4/23/voiceover-accessibility.html Another good overview of iOS accessibility (basically what we covered here). He has also provided a downloadable Xcode project with working code samples illustrating all of the various methods of adding accessibility to an app; developers should definitely should download that and take a look.
We had a kernel panic during the live show last week, and four tech mavens helped me figure out what caused it, George from Tulsa tells us about the new Quicken for Lion: Lion Compatible Quicken FAQ, Import Quicken Essentials Data into Quicken, Buy Lion Compatible Quicken from Intuit for $14.99. Two more reviews from the CSUN Persons With Disabilities Expo, My Talk Tools from mytalktools.com and Charm Tech Capti for a more accessible and enjoyable access to Firefox. Professor asks if there isn’t some way to protect his PowerPC Macs. FlyGrip iPhone and Android accessory from flygrip.com. In Chit Chat Across the Pond Bart goes on a rant about 3rd party cookies, and then gives us the higher division course on home networking, and the advantages of building your own network router.
In order to narrow this down, I took a look at Apple’s best practices for creating a presentation on a Mac for use on an iPad. They suggest only 10 of the possible 44 options in Keynote for the Mac. In describing these themes, I chose to explain the colors, the contrast, and the overall feeling you get when looking at them. I hope this is of some help in choosing a theme if you’re blind. You can read Apple’s Best Practices here: http://support.apple.com/kb/HT4114 Continue reading “Keynote Theme Advice if You’re Blind”
Time Machine review, Blindfolded accessibility update, Photography and the Mac Podcast Promo find it in iTunes. In Dumb Question Corner Professor Albert joins us again asking how to quit all running applications and gets a surprising answer. 3 in 1 Camera Lens review from Rod Simmons. George from Tulsa says some nice things about Podfeet.com and explains that you have to turn off Ad Block to see my Amazon Affiliate link, and then throws down the gauntlet about a lively discussion he and Bart had about Apple’s move towards Sandboxing. Bart comes back with a full Chit Chat Across the Pond explaining Sandboxing and why it’s a good, not scary thing.
The problem to be solved: You have a lovely Novatel 5410L 4G Hotspot from Verizon, but the battery only lasts 4 hours. If you plug it into a computer’s USB high power port, the device automatically goes into charge only mode, and stops providing any wifi access. The steps below will walk you through how to take an ordinary and inexpensive USB cable and make it work to charge the device via USB and remain a hotspot. You may think you can buy a charge-only USB cable, but it turns out those don’t work with this device – you must short the green/white wires together to trick the device into charging and delivering wifi at the same time. Just having a cable with no green/white data pair does not work. Credit goes to bill-mifi at the Verizon Wireless forums for explaining about the green/white wire shorting idea.
BREAKING NEWS! Verizon put out a firmware update for the Novatel Mifi that actually fixes the problem! Here’s a link to the instructions on the Verizon Wireless website where you can get the firmware update, it’s not the most obvious procedure in the world but it works if you follow them carefully.
If you’re still interested, read on!
Basic steps are, we’re going to cut a USB cable in half, short the green/white wires at the micro-USB side, then reconnect the black/red pair. Solder, Electrical tape and we’re done. I found it helpful to show my work every step of the way to Quality Control Director Steve before proceeding.
But first, let’s watch a short video showing the behavior of the Samsung Mifi 4G with a normal USB cable and then with the modified charge-only USB cable.
Video Demonstrating Why This is Necessary
The video above shows the behavior before and after hacking the cable for the Novatel Mifi. Using a screenreader? Click Here
Buy a Micro USB Cable
Actually buy several. If you buy from Monoprice.com, they START at $0.65 apiece, if you buy 2+ they’re only $0.62 apiece. I bought 3 because I knew I would wreck at least 1. I was right.
Tools You’ll need
Couple of Micro USB cables
glasses (if you’re over 40)
Tools I Started With
I prefer the short micro USB cables, here’s how short the ones I suggested are compared ot the mifi. Wire strippers are a must but weren’t as helpful as I thought they’d be.
Cut the Cable in Half
As you can see from this photo – I cut the cable very close to the micro USB end, which was a big mistake (hence the need for the backup cables). I clipped the wire in with the wire cutters, and then actually had to use the box cutter to cut a ring around the cable before I could use the wire stripper to pull off the outer rubber. I might need a new pair of wire strippers!
When I got past the cable cover, I found first a bunch of shielding wires, then under those I found a thin foil covering as well. I cut all of that back to the edge of the rubber cover.
Closeup of the Shielding
This is before stripping the inner wires.
This is where things went wrong – leave yourself PLENTY of length to work with in case you accidentally cut through one of the very thin wires when trying to strip them. Like I did. the wire cutters I have aren’t fine enough, so I was having to use the flat cutter blade they had to just grab and pull and hope for the best.
Short the Green/White Wires Together
This is the critical step. On the Micro-USB end, twist the green and white wires together. the twist the red to the red and the blakc to the black (basically restablishing the connection. Cut the green and white wires on the big USB end as short as you can so they can’t touch anything.
Test Before Taking Next Steps
Test the connection by plugging to the high power USB port. On a MacBook Pro this is the port closest to the power adapter.
I received this error during my first test, but nothing at all went wrong. I didn’t get it again when I had the cable fully stabilized with solder and electrical tape.
Solder the shorted green/white wires, and the reconnected black/red wires. I soldered them so they were essentially in line, and in the next step folded them back on themselves. Hope that makes sense…
Tape The Connections
Tape the shorted green/white wires on the micro-USB end.
Cut the green/white wires short on the non-micro end.
Tape the red wire carefully to ensure no short can happen to the black wire (and vice versa).
Trim back all of the foil and insulation wires
Test again by plugging into your computer to ensure it charges and broadcasts wifi.
Tape the Whole Thing
Finally wrap the whole thing as tightly as you can making sure there’s no unprotected areas, and that you’ve taped onto the original rubber coating so it’s stable.