We take a very research to practice approach, and there are three parts to this. The first is that we look at instructional practices that work in other content areas and we see how they work within computer science education. The second is, and this is a very important thing, we work inclusive classroom environments where there's a wide range of cultural, socioeconomic, and academic diversity. So that when we try to understand how instructional approaches are working for different children, we're able to do it in the context that is wide enough so that we can understand whether what we're learning can be generalized to other settings. And the third is that we work very closely with teachers and administrators, so that the questions we ask are relevant to them. And then, when we come up with instructional strategies, we know that those are ones that can be implemented in the classroom. We're using two different programming environments for our research currently. We're using both Scratch & Code.org. Both of these are graphically intuitive block-based programming languages, which essentially means that rather than having to type code, students get to drag and drop blocks of code so they don't get to get hung up on the syntax. The two examples that we're going to talk about in depth are Scratch & Code.org. They're very different in some ways even though they're both block-based programming languages. Scratch is a very open-ended environment where kids get to explore. This is the language that we use when we're doing integrated computing in mathematics or science because teachers can create pretty much any kind of teaching environment where Scratch can be embedded. As compared to Code.org, which is kind of a sequential puzzle-based way of learning computing as students progress in increasingly more complex computing concepts, they level up. And so, at the end of that, they get to the more open exploratory phases, but they have to go through this much more narrowly constructed pathway to get there. And there are advantages and disadvantages to both so those are the two languages we're using. There are three different instructional practices that we look at when we're thinking about how to support kids with disabilities in computing. The first is Universal Design for Learning. The second is balancing explicit instruction within open inquiry activities. And the third is focusing on collaborative problem solving. Universal Design for Learning is an instructional planning approach that allows teachers to proactively plan for a wide range of variability of students in their classroom. It assumes that students come to the classroom with different backgrounds, with different skills, and with different challenges so it's based on neuroscience. And although this is kind of an oversimplified way of looking at it, it assumes that there are three learning networks, a recognition network. This is the what of learning. And so, we know is that kids are going to learn information in different ways so we want to have a flexible way of presenting that information to them. The strategic network is the how of learning. And so, if we think about how students are showing us that they understand something, we know that they're going to be able to do that in different ways, and they're going to have different preferences in how they do so, which means we have to assess them in different ways. And then, the effective network, which is really the why of learning so this is about motivation. And so what is it about learning that's going to make students really want to learn? What's going to motivate them to learn? And so, if we think about this as three different pieces of learning, we can plan for that. Within the context of computing education, what this means is, we want to provide computing instruction using multiple means of representation. We want to provide them with multimedia ways of learning. We want a model for them ourselves. We want to provide them with pictorial representations. We also want them to be able to demonstrate their understanding in a different way so that we're not just giving them one assignment that they have to provide one answer to. We want to engage them in the material in a different way. So, for example, if they're learning about something like conditionals, which we'll talk about in a moment, they might want to create a story using conditionals. They might want to create a video game using conditionals. Either way, they're demonstrating their understanding but they're doing it in a way that's motivating them. Universal Design for Learning actually started in architecture with physical accessibility. So, think about curb cuts, and think about automatic doors. Those are really important to people in wheelchairs, but they're also really important as I'm walking down the street with a stroller, right? So being able to get up onto the curb or get through the doors when my hands are tied up. Now, the movement towards cognitive accessibility came directly from that architectural movement to make buildings more accessible. So now we think about instructional material and instructional delivery being more accessible. So, an example of that is text to speech, which is really important for people with print-based disability, but it's also helpful to me as I'm trying to listen to what I've written and so I can use text to speech to do so. The current movement is really about all kids. So the Every Student Succeeds Act, which is the latest version of the No Child Left Behind Act, has Universal Design for Learning within it, and has as it relates to assessment, but also as it relates to technology adoption, and that's why it's important in this context. It's also in the latest national education technology plan from an equity and access perspective. So, if we think about the current educational offer for all kids, Universal Design for Learning is in there so we really ought to think about it in terms of computing education as well. Here's some language from the ESSA about Universal Design for Learning. And this is key because what the ESSA says is that it encourages school districts to use technology consistent with the principles of Universal Design for Learning to support the learning of all students, right? It's the all piece of this, just like computer science for all, including students with disabilities and English language learners. But the key here to remember is that universal design is about pedagogically, it's not about the technology. Now, we're talking about the technology but we're doing it within the context of how is it that we're teaching kids in a way that's most accessible to them. Here are a few examples. If we think about multiple means of representation, we might want to a model computing lessons for kids using an interactive whiteboard. We might want to use already created templates and use those with students. In terms of having them express their understanding, we might also have students be able to create code from scratch, but we might have them complete partially completed codes from a template. And in terms of providing different ways for them to engage in the content, we might want to give them different options for choices and projects in how to display their projects. And so, if we think about UDL from the perspective of the pedagogical approach, what we want to do is start teaching CS from this very flexible framework, and then evaluate our kids learning, are they engaged? And then, for some students with disabilities, we're going to have to layer some level of individualization on top of that for them. So, for example, student with a very significant learning disability, we might really need to do some additional verbal prompting with them, even if the instruction is universally designed, or a student with a visual impairment, we might really need to still use some assistive technology for them. Then, we're going to re-evaluate to see how is the learning going, how is engagement going. And then, if they're still not engaged or learning, we're going to go back to that instruction, and see what additional layers of support we can give. So, the idea is, if a student is struggling, our first inclination should not be they're struggling, they can't do it. It should be what is it that we can do on top of what we're already doing to increase access and engagement. So, another approach that we do is we think about balancing explicit instruction with open inquiry. So, computing is supposed to be fun and open-ended, but because of that, it's also complex so that level of student-driven instruction on one hand is very motivating for kids because they're able to explore and create on their own. On the other hand, they're not able if they're struggling to get any help within that kind of environment. And so, embedding some level of explicit instruction is helpful. What we know from the research is that for students with disabilities especially having the process broken down for them so that they can still see step by step what to do, having the teacher monitor whether they're learning, and then providing them with feedback, is a really important critical thing for some students. And now, this is very teacher directed as compared to computing, which is usually very student directed. So, you see that teachers can have a really difficult time with that. And we want to balance this, right? So we don't want to just have students being provided with explicit instruction because, then, they'd never learn how to problem solve. And we don't want it to be so open-ended that they're giving up because it's too difficult. So what we're studying right now is how do we balance these approaches together. So, Archer and Hughes, in 2011, came up with a list of about 15 different kinds of explicit instruction processes. And here are just three of them. One is focusing instruction on critical content. So being very explicit about what is it that we want to teach the kids and letting them know what that is, and then providing step by step demonstrations of how to break down complex tasks, and then having numerous opportunities for practice. So, in a computing environment, this may mean that we're going to teach students the skill of using conditionals, and I will show you an example of that in just a moment. And then, we're going to model for them, how to use those blocks of computing code. And then, we're going to provide lots of supports, guiding questions, as students are able to go through this, encouraging risk taking so that they can be successful. One of the teachers we work with at Kenwood Elementary School here in Champaign Unit 4 wanted to teach kids about conditionals and what conditionals are. There expressions that are evaluated as either true or false, to determine the program flow. And so, there are essentially logic statements. So, if the condition is true, you do one thing. If the condition is false, you do another thing. So the way this teacher scaffolded this for kids is first she started with a worksheet with if then statements, and they were able to use those in real world situations. Once they were able to understand that, then they played a card game with red and black cards. If you get a black card, you get two points. If you get a white card, you lose a point, right? So every condition has a consequence that happens. And then, only after the students were able to really understand that, then they were using the programming language. So,\ here's an example of that. So she had the students write different conditions, different conditionals, and that they do at school and at home. So, if I do my homework right when I get home from school, then I get to watch 30 minutes of television. So that's an example of it conditional. A really funny example is the picture there, where you can't see is that there is a water fountain right underneath there. And what this conditional statement say is, if I'm thirsty, then I'm going to drink for less than three seconds, and then I'm going to go to the back of the line. And so, it's kind of a funny way to teach that concept, but it's a real world example. And only after that were students introduced to the block within scratch, the if then block.
