Note: This blog post is a work in progress. I wanted to start this conversation as soon as possible, while the Hour of Code is going on. I will update the post throughout the week with additional information and resources, including a video showing the Tickle app working with VoiceOver.
As some of you already know, this week is the Hour of Code. From hourofcode.com:
The Hour of Code takes place each year during Computer Science Education Week. The 2016 Computer Science Education Week will be December 5-11, but you can host an Hour of Code all year round. Computer Science Education Week is held annually in recognition of the birthday of computing pioneer Admiral Grace Murray Hopper (December 9, 1906).
I have nothing against coding and I do not mean to rain on the excitement that so many of my educator friends have about this event. Used wisely, coding can be an effective way to engage learners who have traditionally not found something to be excited about in their education. Used blindly (pardon the pun coming from me) it can be another way to further narrow the focus of the curriculum and leave some kids behind. That’s what I want to focus on in this short post.
First, I want to make clear that I truly believe “everyone can code” or should at least have the opportunity to explore coding. The question is does everyone want to code? If I am artist, or a writer, or a performer, then these activities are the ones that are going to engage me with learning. I believe in Universal Design for Learning and providing options so that all learners can find the entry point to learning that works best for them. If we focus too narrowly on coding, we may actually be creating an environment where some learners (and their passions and interests) are left behind. Rather than focusing on the specific skill of coding, why not focus on design thinking and incorporate coding into project based learning and more broadly defined approaches? I believe this is what is going to prepare learners to solve the big problems we face now and in the future. Ok, I will get off my soapbox. There are people with far more expertise in computer science education who can make this argument in a more eloquent way than me.
What I do want to focus on today is the aspect of coding and computer education that I am finding most troubling: the lack of accessibility in the many apps and tools available to educators. For a long time, print was the biggest barrier to learning for those of us who have any kind of disability such as blindness, dyslexia or other print disabilities. We are now making progress in that area. Digital text is a much more accessible format because it can be easily transformed into a variety of formats as needed. A learner who is blind can access print content on a computer or mobile device with the help of a screen reader, software that takes the text and converts it to audio (or even Braille with the addition of a separate Braille display). Text to speech has advanced greatly, with higher quality voices and more accurate reproduction of the print content than ever before. And finally, when print is the only option available, Optical Character Recognition (OCR) has improved and made the conversion to more universal formats much easier. In some cases, this can even be done using the camera on a mobile device with apps such as Prizmo and kNFB Reader.
There is currently a push to make coding into one of the basic literacy skills our learners should possess, along with reading, writing and math. I have no problem with that. What I do have a problem with is the fact that accessibility is not even on the map with a lot of the developers in this space, with only a few exceptions. If we don’t pay attention to accessibility, coding will become the new print- one more barrier for our diverse learners to overcome.
Over the last few months, I made it my mission to try out as many apps and tools for teaching coding as I could. I even looked at a few of the toys that can be programmed through code written on an app, and bought one of those toys myself. I was greatly disappointed when I opened the apps and found a general lack of even the most basic accessibility practices – buttons that were left unlabeled, or parts of the app that were completely inaccessible with a screen reader. Now, I understand that in some cases it is difficult to make the app accessible due to its visual nature, but surely you can at least make the basic interface accessible. That would at least allow someone who needs accessibility support to participate in some of the activity. As it is, he or she can’t participate at all when key aspects of the app are not accessible.
The excuse is even more difficult to accept when there are apps/tools that are at least trying to make coding accessible. They are not perfect, but they have at least shown that progress can be made, and that’s all I am asking for -at least consider accessibility, give it a shot, and then let the community help you by providing feedback and then listening and incorporating it into your updates. Here are two tools that are doing a great job of incorporating accessibility into coding:
- Apple’s Swift Playgrounds: As usual, Apple leads the way with its Swift Playgrounds app. Swift Playgrounds is a free app that runs on iPad, as long as that iPad is running iOS 10 or later. Rather than go into all of the details of Swift Playgrounds here, I recommend you check out fellow ADE Michelle Cordy’s post on Swift Playgrounds. It is very comprehensive and links to many resources to help you get the most from Swift Playgrounds. Thank you Michelle! Want to see Swift Playgrounds being used with Switch Control? The Switch Master Christopher Hills has done a video showing just that.
- Tickle: With Tickle, you can program LEGO, Star Wars BB-8, Arduino, Sphero and other robots, and even smart home devices, all wirelessly. Tickle uses a simple to learn block programming approach, but you can peek under the hood to see the Swift 3.0 code at any time. The Tickle team has done a great job of labeling the interface elements of the app, as shown on this video:
Coding and the tools used to teach it don’t have to be inaccessible. With just a little bit of work, they can be accessible to all learners. Only when that’s the case can we really claim that “everyone can code.” My call to action for you is to contact the developers of the apps you want to use and ask them about accessibility – ask them if it is something they have considered. As a next step, learn how to test your apps for basic accessibility. Basic navigation with VoiceOver is pretty simple to learn and you can then at least have a quick look at the app to make sure its interface has the proper labeling needed by your learners who rely on assistive technology.
The future of work is definitely changing. Manufacturing jobs that once promised to be a ladder for upward mobility are disappearing fast and will probably not return. The future may well be in technology for many of our learners, but we need to make a concerted effort to ensure the path to success is open to all during this period of transition. The statistics paint a bleak picture when it comes to STEM careers for individuals who have disabilities. Ensuring that the tools we use to teach coding and basic computer science concepts are accessible are a first step toward building a better future for all of our learners. Only then will we be able to say that not only “everyone can code” but also everyone can be a computer scientist, a software developer or anything they want to be.