How to Build Accessible iOS Apps

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:

Donald Burr on Accessible App Development

How to Build Accessible iOS Apps by Donald Burr

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).
  • Some actual examples from the Otaku no Podcast app: https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
    Look at “OnP main screen – play latest button,” “OnP main screen – refresh button,” and “OnP player screen – graphical play button”
  • Custom UI elements

    • 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.
    • All accessibility information can be set in code.
    • Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “adding to code 1” and “adding to code 2”

    Accessibility Containers

    • 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.)
    • Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “container code 1” and “container code 2”
      Another good (more real life) example can be found in the Use Your Loaf TaskTimer project (see below); look at theUYLCounterView.m file

    Accessibility Actions

    • If you are creating a custom adjustable control, you need to give VoiceOver information on how to manipulate its value.
    • VoiceOver has two standard gestures: swipe up (increases the value of something) or swipe down (decreases it).
    • So when coding your custom control, you need to create special “increment” and “decrement” code that VoiceOver can use to change its value.
    • A good example of this is the page turner in iBooks (the little dotted line with the box at the bottom that lets you quickly page through a book).
    • A third type of gesture is “scroll.” This is meant for a control that scrolls to a different part of your UI. Example: moving between home screens, or scrolling between cities in the Weather app.
    • Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “action code 1” and “action code 2”

    UI Changes

    • 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.
    • UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
  • 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.
    • UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
  • 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.)
    • UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @”Loading complete.”);

    VoiceOver-specific API

    • Sometimes it is useful to determine whether or not VoiceOver is running, and to do different things depending on whether it is or not.
    • A program can, at any time, test to see whether VoiceOver is enabled or not.
    • if (UIAccessibilityIsVoiceOverRunning()) {
      // VoiceOver is active; do something different
      }else {
      // VoiceOver is NOT active; do the usual thing (whatever that may be)
      }
  • Also, programs can sign up for the system to notify them whenever the VoiceOver status changes.
    • [[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(handleVoiceOverStateChange:) name:UIAccessibilityVoiceOverStatusChanged object:nil];
  • 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.
    • accessibilityElementIsFocused
    • accessibilityElementDidBecomeFocused
    • accessibilityElementDidLoseFocus
  • 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.
  • Testing Accessibility

    • 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.
    • Example: https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “Accessibility inspector”
  • On real devices
    • 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.
  • Miscellany

    • 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.)
  • Resources

    The obligatory plugs section

    • Check out my iOS apps!
  • My portal site – links to everything I do, as well as houses my blog. http://DonaldBurr.com/
  • I’m on twitter as http://twitter.com/dburr/
  • And finally, if you are at all interested in Japanese animation (Anime), comics (Manga), food, travel, culture, etc., check out my podcast, Otaku no Podcast. http://otakunopodcast.com/
  • #357 Kernel Panics, Quicken for Lion, My Talk Tools, Capti, FlyGrip, Home Networking

    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.


    Continue reading “#357 Kernel Panics, Quicken for Lion, My Talk Tools, Capti, FlyGrip, Home Networking”

    Keynote Theme Advice if You’re Blind

    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”

    #338 Time Machine, Blindfolded, Photography and the Mac, Quit All Apps, 3 in 1 Camera Lens, Apple Sandboxing

    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.

    itunes
    Continue reading “#338 Time Machine, Blindfolded, Photography and the Mac, Quit All Apps, 3 in 1 Camera Lens, Apple Sandboxing”

    How to Make Your Own Charge-Only USB Cable for the Novatel Mifi

    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

    wpid2939-media_1314572077638.png

    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
    • wire strippers
    • wire cutters
    • box cutter
    • electrical tape
    • scissors
    • soldering iron
    • solder
    • glasses (if you’re over 40)

    Tools I Started With

    wpid2932-3_IMG_2527.png

    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

    wpid2933-4_IMG_2528.png

    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

    wpid2934-5_IMG_2530.png

    This is before stripping the inner wires.

    Too Short!

    wpid2935-6_IMG_2532.png

    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

    wpid2938-IMG_2535.png

    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

    wpid2936-8_IMG_2535.png

    Test the connection by plugging to the high power USB port. On a MacBook Pro this is the port closest to the power adapter.

    Odd Error

    wpid2937-9_IMG_2539.png

    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

    wpid2929-11_IMG_2544.png

    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

    wpid2930-12_IMG_2546.png
    • 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

    wpid2931-13_IMG_2547.png

    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.

    Do a final test and celebrate!

    Record Your Own Review

    We’re very lucky on the NosillaCast because so many people contribute fantastic reviews or record their Dumb Questions. I often get questions on the best way to record, how long the reviews should be and the best way to get the recording to me. These quick instructions will tell you everything you need to know.

    How Long Should it Be?

    I find that people like guest recordings in the 3-5 minute range so try to stay under that limit (it’s not easy to do that short)

    How to Record

    Hardware to Record:

    • Use any USB microphone hooked to your computer (don’t use the microphone jack though)
    • If you don’t have a USB mic, you can even use the internal mic, do a test recording and ask yourself if you’d like to listen to it
    • Important bit – make sure you wear headphones so you don’t get feedback into your computer from the speaker
    • Use your iPhone – it makes an m4a file that is quite good actually

    Software to Record:

    • The Open Source Audacity from audacity.sourceforge.net is cross-platform and free, so what’s not to like? It’s a little clunky looking but it works perfectly on the Mac, Windows and Linux.
    • If you have a Mac, Garageband works quite well and it’s already installed on your Mac anyway
    • One more point – if you have a choice, make sure it’s a 16bit AIFF (32bit won’t import to iTunes)

    Format for Recording

    The best format is an uncompressed format (AIFF or WAV) because when I get it, I’ll be adding it to my own recording and then compressing it. If you send it as an MP3, it will be compressed twice. It won’t be horrible but why not make it the best it can be!

    Garageband isn’t obvious in how to save uncompressed. If you create your recording as a podcast, you won’t be able to save it uncompressed. Hide the podcast track and then choose export, and UNcheck the compress box. That will create an AIFF file.

    For Audacity you’re in luck – I create an Audacity Tutorial for Podcasting. Just stop before I teach how to compress to an mp3 and you’ll have an AIFF or WAV file.

    Don’t Forget to Send the Script & Links

    Remember that we have a lot of people who like to read rather than listen to the show, and there’s the deaf who can’t listen, so if you use a script (which makes it easier to stay under 5 min) be sure to send it to me. Even if you don’t use a script, if you can give some bullet points that’s good too. And don’t make me go hunting you down to get the links to the products you’ve reviewed, send them the first time! Oh – and don’t forget to plug your own work, if you’ve got a blog or a podcast of your own, or you just want people to follow you on Twitter, send me that too!

    How to Send it to Me

    If you keep your recording down to the 3-5 minute limit, you can probably email it to me. If your email provider won’t tolerate that large of a file, here’s some other options (and there are many more):

    • Put it in Dropbox or OneDrive or some other cloud sharing service and email me the shared link
    • YouSendIt – free account at yousendit.com to send files up to 100MB

    Where to Send It

    Send your reviews, Dumb Questions, comments to allison@podfeet.com

    #289 Automator, Zumocast, iStopMotion, Shai

    No PivotTable Charts in Excel 2011, Kirschen Seah gives us her Add Prefix String Automator action at http://www.freerangecoder.com. Zumocast from zumocast.com vs. AirVideo for video watching on the iPad. Accessible Mind Sweeper from Programar a ciegas at programaraciegas.es. iStopMotion review from boinx.com including Bastian Wolfe’s hysterical video and my 1 second stop motion movie. In Chit Chat Across the Pond performing artist Shai Yammanee of shaiyammanee.com joins us to talk about the tools he uses in photography, video and audio recording.

    itunes Listen to the Podcast Once (1 hour 20 minutes)
    Continue reading “#289 Automator, Zumocast, iStopMotion, Shai”

    How To Disable Java in Chrome

    Quick tutorial on how to disable java on Google’s Chrome browser for the Mac.

    Open Preferences

    wpid3159-media_1288358195154.png

    In the menu bar, select Chrome and pull down to Preferences.

    Under the Hood

    wpid3161-media_1288358218601.png

    In Preferences select Show Advanced Settings…

    Content Settings

    wpid3162-media_1288358474840.png

    Scroll down to Privacy and click Content Settings…

    Scroll Down to see Plug-ins

    wpid3163-media_1337472991097.png

    Click Disable individual plug-ins…

    Disable Java

    wpid3164-media_1337473003411.png

    Click the Disable link under Java

     

    * Note: Craig Reynolds pointed out that in the future you can get to the plugins page faster by simply typing in the URL bar:

    chrome://plugins/

    Posts navigation

    1 2 3 4 5 6 7 8
    Scroll to top