Personal Blogs

I’ve been to a couple of events at the British Computer Society (BCS) before. This one was especially interesting for a number of reasons. Firstly, there are over ten thousand students with disabilities studying at the Open University, and it’s important to know what is going on in the field. Secondly, accessibility in higher education is central to a module that I tutor (H810 accessible on-line learning). Another reason, of course, was to catch up with colleagues in other institutions who work in the digital accessibility sector.

This blog post is intended for internal (and external) colleagues, and students who are studying this area. What follows is a quick summary of all the talks I attended. I also hope this summary might be useful for anyone who was at the conference.

Introductions and opening talks

The conference had the subheading: ‘meeting the needs of the increasing number of students with disabilities’. Lord Addington, spokesman for Special Educational Needs (SEN) at the House of Lords, introduced the event. He spoke about the political context, highlighting the importance of employers. A really important point was: ‘please make sure everyone knows what you can do, to make someone’s life slightly easier; let them know you have practical solutions when you talk to people outside this room’.

Accessibility for students with disabilities

The first speaker was Majid Kahn, who spoke about his experience as an undergraduate student who has a visual impairment. An early point that directly resonated with my own knowledge was the difficulties that can surround acquiring assistive technology through the UK Disability Support Allowance (DSA). Due to delays that are inherent in the process, Majid had to obtain a ‘loan’ computer from the RNIB, which arrived one month after the start of a course.

Majid said (according to my notes) that some software not was accessible through a screen reader. An accompanying challenge was accessing text books (and some books that published in PDF format are not accessible). A practical solution was to directly email the author, who could send a Word version (which would then be accessible). Since many documents and resources are accessed through institutional learning environments, Majid commented that ‘Moodle seems to be inaccessible at the moment’. This was a point that I found interesting, since I know the OU has been putting a work into trying to make Moodle accessible. Perhaps there might be differences between how Moodle is set up and used by different institutions.

Another key point was that the training available at university (in terms of how to use systems, products and assistive technologies) is not adequate. This was connected with the view that although things are heading in the right direction, there is a long way to go, and there is a lack of awareness. Awareness is connected to the importance of communication, and the acceptance that every student is different. In some situations, students may be reluctant to ask for help and advice, and some lecturers might be unwilling to offer additional support. To help to facilitate understanding it was considered important to share information; to help university staff to become more aware of the needs of students. 

An industry perspective on what to teach and how

David Sloan is an ‘accessible user experience engineer’. I know David through his publication on the notion of holistic web accessibility (Word doc, University of Bath). David’s job is to provide advice on how to develop and support digital accessibility, which is something that is often thought of ‘very late in the day’, or is considered as an afterthought.  Put another way: ‘organisations pay us to give bad news’. Rather than reporting on what doesn’t work, organisations and universities shouldn’t really focus on ‘evaluating and repairing’, but should instead focus on ‘improving practices and processes from the beginning’.

Some key problems include the lack of web development skills, understanding that not everyone uses a mouse for access, the use of colour, and media accessibility, i.e. offering alternative (useful) descriptions for graphics.

A fundamental problem can relate to the organisational perspective; accessibility not being connected to good experience design, or accessibility being ‘hived off’ into another part of interaction design. The key point is that accessibility needs to be built into development processes, and this relates to the idea of an ‘accessibility design maturity continuum’ http://uxfor.us/mature-it (Paciello group); accessibility shouldn’t be added as an afterthought.

There are a number of challenges for educators: the importance of integrating accessibility into the curriculum, that digital literacy and accessibility communication should be embedded into all subjects (and not just information technology or computing sciences), and that it should be integrated into learning activities, experiences and assessment. It is also important to include accessibility as a core professional skill.  David went on to suggest that there might be increased professionalization of accessibility, and mentioned something called TeachAccess.org (TeachAccess website).

As David was talking, I had a thought which relates to the complexities that are inherent in accessibility. Whilst it is possible to create accessible resources and accessible software, every learner is different in terms of their personal needs and their learning strategies. Learners need to develop expertise and mastery over their tools. This is, of course, something that takes time.

Accessible STEM: Anticipating and resolving barriers

Emma Cliffe works in the accessibility resource centre in the University of Bath. Emma helps to provide accessible solutions for maths, computing, and subjects that present a lot of diagrams.

When it comes to maths, a really important point is that students are expected to produce assignments that their lecturers can read; students invariably need to show their working to demonstrate their understanding of mathematical concepts. One of the issues is that some digital formats (such as PDFs, for example) are ‘lossy’, which means that they lose some of their important semantic information when PDF documents are created.

Lecturers need to provide materials in a format that retains the ‘semantic structure’ (or meaning) of the maths that they aim to teach. Emma mentioned a range of tools and formats: structured Word documents, structured HTML documents, MathML, or Tex plus something called MathJax, Markdown, or ePub3. 

As a brief aside, Tex is a typesetting language which is used with Latex, which mathematicians often use to write technical papers. I’ve used Latex in anger only once, and found it very difficult! I hadn’t heard of something called MathJax before.

 A key question is: how do you author mathematics? The answer is: it is a skill that needs to be learnt (and, of course, takes time to master). This area is one that is rapidly changing, and is difficult for disabled support allowance (DSA) assessors to keep up.

Emma moved onto looking at a subject that that cropped up in my undergraduate studies: finite state automata, which are usually represented through diagrams (using circles and arrows). A finite stage machine is an abstract machine that moves between different states of operation. The thing is, it’s pretty difficult to describe them. To emphasise this point, we were shown different types of descriptions, some more descriptive and wordy than others.

Reflecting on David’s session, I noted that we need to help students to find a choice of tools that work for them. We also need to embed accessibility into procurement processes, and figure out how to integrate accessibility in our teaching (since non accessible students can also benefit from any adjustments that we make). Collaboration is, of course, important too.

Accessibility and MOOCs

EA Draffan from the University of Southampton spoke of a range of different issues that related to accessibility. One point (and I don’t know whether this is true) is that the majority of learners are either middle aged, or elderly.

EA made the really important point that all technologies can be assistive. Some important questions to ask those working in the academic context are: why are we using certain types of multimedia? What are its barriers for use? Do all learners need it? Is personalisation possible?

Rather than presenting research findings, the main point of EA’s presentation seemed to be: MOOC designers and developers need to be mindful about the importance of accessibility. EA went onto talk about different types of accessibility checkers. (There is, of course, the accompanying issue that it can be sometimes difficult to understand and interpret the results from these checkers).

On the subject of MOOCs, I have a couple of research questions (one of which was touched on by EA). The first one is: what do MOOCs about accessibility actually teach? And, secondly, are MOOCs themselves accessible? What are the practical barriers that learners face, and what do they do to get around them?

Parallel session: accessible and adaptable materials and content

The afternoon parallel session consisted of three presentations. The first talk was about ‘how to make PDF documents accessible in virtual environments’, and was given by colleagues from AbilityNet (AbilityNet website). The advice was simple, familiar and effective: create documents using accessible tools, know your audience, don’t use long paragraphs, use headings, use bullet points to break up text, avoid graphics of text, don’t use colours to provide information, and use alternative text for images. Importantly: always consider the semantic structure of a document.

Next up, was an accessibility consultant called Ted Page, who said there were differences between technical accessibility and content accessibility. I think this means that event though something might be accessible through assistive technology, the corresponding content, if read out by a screen reader, might not make any sense at all. PDFs are, apparently, a reasonable solution, but I was interested to hear that MathML is coming to PDF documents (which should add more semantic structure to documents). This echoes Emma’s point that this is a fast moving area.

The third presentation from this session was by Joanna Hunt, from Blackboard. Joanna spoke about a new on-line real-time conferencing system that may replace Elluminate (which is the basis of OU Live, the OU’s real-time tutorial system), which relies on a Java plug-in. This additional bit of Java software can sometimes be a barrier for users. This connects to a wider point that usability and accessibility are intrinsically connected. Unfortunately, I didn’t get a feel for how the new Blackboard system may work (and its accessibility) since it is still under development.

Closing Keynote: Employment prospects of STEM graduates with Disabilities

Peter Looms, from the Technical University of Demark addressed a range of wider issues. Not only is accessibility important in terms of learning resources and classroom activities, but equal access to social activities (of course) is also important. This point is related to the social model of disability. There should be a movement away from solving problems, to removing barriers.

Other points related to the costs of exclusion: there are societal and economic impacts. Assistive technology and digital tools can often be expensive. There are also benefits to inclusion. Peter mentioned Kyle Schwanke, a Microsoft Xbox engineer who has ASD, and touched on the importance of diversity and recruitment. (More information about Kyle Schwanke can be found in a Microsoft People article). The point is that diversity should be viewed as an asset, not a burden. 

Discussion and reflections

During each of the two parallel sessions, each group was asked to consider what might be four points (or steps) to digital accessibility.

Here is a list of the combined points: the importance of consultation (with students), professionalise good teaching practice, improve access to information, put skills before disability (and use the social model of disability), consider using game technology for educating tutors, the importance of doing things the right way, the importance of standards, the importance of involving users, training tutors, and working together.

The final discussions centred upon whether the BCS could embed more accessibility into its core mission, and the extent to which the Teaching Excellent Framework (Times Higher article) may influence practice.

My main concluding thought is that there was one aspect to the conference that wasn’t a surprise, and another aspect that was a surprise. In some respects, all of the subjects and issues that were discussed were quite familiar to me: I am aware of the challenges that surround mathematics, and that we should not be ‘retrofitting’ accessibility to digital materials (but should, instead, think about accessibility from the outset). The surprise was the feeling that there is still a long way to go when it came to educating people about the importance of accessibility.

There are (at least) two reasons why it is important. Firstly, making something accessible, makes things easier for everyone. Secondly, we a moral and a legal responsibility to do something about it. 

For those who are interested, resources from the conference have been made available on the BCS website.

When I was a graduate student at the University of Manchester (or the bit of it that was once known as UMIST) I was once asked to show some potential computer science students around the campus.  At the end of the tour I ushered them to lecture which was intended to give the students a feel for what things would be like if they came to the university.

The lecture, given by one of the faculty, was all about the notion of abstraction.  We were told that this was a fundamental concept in computing.  In some respects, it felt less of a lecture about computing, but more of a lecture about philosophy.  I had never been to a lecture quite like it and it was one that really stuck in my mind.  When I left the lecture, I thought, 'why didn't I have this kind of lecture when I was an undergraduate?'  As an undergrad I had spent many a hour creating various kinds of computer programs without really being told that there was an essential and fundamental idea that underpinned what I was doing.

When I saw the British Computer Society (BCS) advertising a lecture that was about the 'power of abstraction', I knew that I had to try to make time to come along. The lecture, by Professor Barbara Liskov, was an annual BCS lecture (the Karen Spärck Jones lecture) that honours women in computing research.

All this sounds great, right?  But what, fundamentally, is abstraction?  An 'abstract' at the top of a formal research paper says, in essence, what it contains.  Abstraction, therefore, can be thought of as a process of creating a representation of something, and that something might well be a problem of some kind.  Admittedly, this sounds both confusing and vague...

Barbara began her lecture by stating that abstraction is the basis of how we implement computer software.  The real world is, fundamentally, a messy place.   Since computers are ultimately mathematical machines, we need a way to represent problems (using, ultimately, numbers) so that a computer can work with them.  As a part of her lecture, Barbara said that she was going to talk through some developments in the way that people (or computer programmers) could create and work with abstractions.  I was intrigued; this talk wasn't just about a history of programming languages, it was also a history of thought.

So, what history was covered?  We were immediately taken back to the 1970s.  This was a period in computing history where the term 'software crisis' gained currency. One of the reasons was that it was becoming increasingly apparent that creating complex software systems was a fundamentally difficult thing to do.  It was also apparent that projects were started, became excruciatingly late and then abandoned, costing astronomical amounts of money. (It might be argued that this still happens today, but that's a whole other debate which goes beyond this pretty short blog post).

One of the reasons why software is so fundamentally hard to create is that it is 'mind stuff'.  Software isn't like a physical artefact or product that we can see. The relationships between components can easily become incredibly complicated which can, in turn, make things unfeasibly difficult.  Humans, after all, have limited brain capacity to deal with complexity (so, it's important that we create tools and techniques that help us to manage this).

We were introduced to a number of important papers. The first paper was by Dijkstra, who wrote a letter to the Communications of the ACM entitled, 'Goto considered harmful'.  'Goto' is an instruction that can help to create very complicated (and unfathomable) software very quickly.  Barbara described the difficulty very clearly. One of the reasons why software is so hard is that there is a fundamental disconnect between how the program text might be read by programmers and how it might be processed or executed by a machine.  If we can create a program representation that tries to bridge the difference between the static (what is described should happen) and the dynamic (what actually happens when software does its stuff), then things would be a whole lot easier.

Another paper that was mentioned was Wirth's 'program development by stepwise refinement'. Wirth is famous for the design of two closely related languages: Pascal and Modula-2. It certainly is the case that it's possible to write software without the 'goto' instruction, but Barbara made the interesting point that it's also possible to write good, well-structured software in bad languages (providing that you're disciplined enough). The challenge is that we're always thinking about trade-offs (in terms of program performance and code economy), so we can easily be lured into doing clever things in incomprehensible ways.

Barbara spoke about the importance of modules whilst mentioning a paper by Parnas entitled, 'information distribution aspects of design methodology'. One of the great things about modules, other than that they can be used to group bits of code together, is that they enable the separation of the implementation and the interface.   This has reminded me of some stuff from my undergrad days and time spent in industry: modules are connected to the term 'cohesion'.  Cohesion is, simply, the idea that something should do only one thing.  A function that has one name and does two or more things (that are not suggested in its name) is a recipe for confusion and disaster.  But I fear I'm beginning to digress from the lecture and onto one of my 'coding hobbyhorses'.

Through a short mention of a language called Simula-67 (Wikipedia) we were then introduced to a paper by Liskov and Zilles entitled, 'programming with abstract data types'.  We were told that this paper represented a sketch of a programming language which eventually led to the creation of a language called CLU (Wikipedia), CLU being short for Clusters.

There is one question Barbara clearly answered, which is: why go to all the trouble of writing a programming language?  It's to understand whether an idea works in practice and to understand some of the barriers to performance.  Also, whenever a language designer describes a language in natural language there are always going to be some assumptions that the compiler writer must make. Only by going through the process of creating a working language are language designers able to 'smoke out' any potential problems.

Just diverting into programming language speak for a moment, CLU implemented static type checking, used a heap, and doesn't support concurrency, the goto statement or inheritance.  What it does implement is polymorphism (or the use of generics), iterators and exception handling.

Barbara also mentioned a very famous language called Smalltalk, developed by Alan Kay.  Different developments at different times and at different places have all influenced the current generation of programming languages.  Our current object-oriented languages enable programmers to define abstractions, or a representation of a problem in a way that wasn't possible during the earlier days of software.

Research directions

Barbara mentioned two research topics that continue to be of interest.  The first was the question of what might be the most appropriate design of a programming language for novices?  In various years, these have been BASIC (which introduced the dreaded Goto statement), Pascal, and more recently Java.  Challenges of creating a language that helps learners develop computational thinking skills (Wikipedia) include taking account of programming language design trade-offs, such as ease of use vs. expressive power, and readability vs. writeability, and how to best deal with modularity and encapsulation.

Another research subject is languages for massively parallel computers.  These days, PCs and tablets, more often than not, contain multiple processor cores (which means that they can, quite literally, be doing more than one calculation at once).  You might have up to four cores, but how might you best design a programming language that more efficiently allows you to define and solve problems when you might have hundreds of processors working at the same time?  This immediately took me back to my undergrad days when I had an opportunity to play with a language called Occam (Wikipedia).

There was one quote from Barbara's lecture that stood out (for me), and this was when she said, 'you don't get ideas by not working on things'. 

Reflections

I should say at the point that I haven't done Barbara's speech justice.  There were a whole lot of other issues and points that were mentioned but I haven't touched on.  I really enjoyed being taken on a journey that described how programming languages have changed.  I liked the way that the challenges of coding (and the challenge of using particular instructions) led to discussions about modules, abstract data types and then to, finally, object-oriented programming languages.

It's also possible to take a broader perspective to the notion of abstraction, one that has been facilitated by language design.  During Barbara's lecture, I was mindful of two related subjects that can be strongly connected to the notion of abstraction.  The first of these is the idea of design patterns.

Design patterns (Wikipedia) take their inspiration from architecture. Rather than design a new building from scratch every time you need to make one, why not buy a pre-existing design that has already solved some of the problems that you might potentially come up against?  There is a strong parallel with software: developers often have to solve very similar problems time and time again.  If we have a template to work from, we might arguably get things done more quickly and cheaply.

Developers can use patterns to gain inspiration about how to go about solving common problems.  By using well understood and defined patterns, the communication between programmers and developers can be enhanced since abstract concepts can be readily named; they permit short-cuts to understanding.

In some cases, patterns can be embedded into pre-existing code that can be used by developers to kick-start a development.  This can take the form of a framework, software code that solves well known problems that ultimately enables developers to get on and solve the problems that they really need to solve (as opposed to dealing with stuff such as reading and writing to databases).

Abstraction has come a long way in my own very short career as a developer. One of the biggest challenges that developers face is how to best break down a problem into structures that can be represented in a language that a machine can understand.  Another challenge lies with understanding the various tools that developers now have at their disposal to achieve this.

Note: The logo at the top of the blog is used to indicate that this blog relates to a BCS event and this post is not connected with the BCS in any other way. All mistakes and opinions are my own, rather than that of the OU or the BCS.