Description and Reflection

Legislation

The Disability Discrimination Act 1995 (DDA) is formally "An Act to make it unlawful to discriminate against disabled persons in connection with employment, the provision of goods, facilities and services or the disposal or management of premises; to make provision about the employment of disabled persons; and to establish a National Disability Council." Originally, it did not apply to students, but the Special Educational Needs and Disability Act 2001 inserted new provisions in Part 4 of the DDA in connection with disability discrimination in schools and other educational establishments, and so effectively made the DDA apply to students.

The DDA was repealed and replaced by the Equality Act 2010, except in Northern Ireland where the DDA still applies. The Equality Act 2010 essentially merged various previous equality and anti-discrimination acts, but it is disability that I want to focus on. In the case of disability, employers and service providers are under a duty to make reasonable adjustments to their workplaces to overcome barriers experienced by disabled people. In this regard, the Equality Act 2010 did not change the law and I will continue to refer to the relevant legislation as the DDA.

The devil in the detail of the DDA is the meaning of "reasonable adjustments". The United Nations uses a closely related term in the Convention on the Rights of Persons with Disabilities, saying that refusal to make accommodation results in discrimination and asserting that:

“Reasonable accommodation” means necessary and appropriate modification and adjustments not imposing a disproportionate or undue burden, where needed in a particular case, to ensure to persons with disabilities the enjoyment or exercise on an equal basis with others of all human rights and fundamental freedoms.

Determining the meaning of "reasonable adjustments" will no doubt keep a multitude of lawyers in gainful employment for the foreseeable future, but in the context of making electronic documents accessible I consider that it means:

• using appropriate technology, such as typing documents into a computer using document processing software rather than hand writing them and scanning the results to produce image files;
• using appropriate document structure, which is properly accessible both visually when rendered on a screen (or printed) and when the file is reprocessed, such as by a screen reader or other assistive technology;
• doing a small amount of extra work to produce electronic documents that could have their accessibility enhanced by further processing if necessary, such as semi-automatically adding WAI-ARIA markup to an HTML document or converting a (L^A)TEX document to HTML+MathML.

Fonts

Choice of fonts can have a bearing on the accessibility of text. There is information on the web about font choices but I find the guidance to be somewhat ambiguous and subjective. However, I think it is broadly agreed that dyslexic readers find sans-serif fonts easier to read than serif fonts because the serifs constitute distracting decoration, and I think it is broadly agreed that sans-serif fonts are easier to read than serif fonts when displayed digitally in relatively low resolution (less than around 300 dpi) because the serifs cannot be displayed clearly and so end up blurred or bigger than they should be, thereby distorting the glyphs.

On the other hand, there is evidence that a serif font is easier to read if the glyphs are partly obscured because the serifs provide redundancy that helps to disambiguate the glyphs. However, this is not very likely to happen in practice. I think that the strongest argument against sans-serif fonts is that some glyphs are ambiguous. In normal text, the context is enough to remove any ambiguity, but in a few special cases it is not and using a sans-serif font is a disaster! For example, strong passwords should consist of a mix of upper and lower case letters, digits and possibly also special characters. They need to be displayed using a serif font in order to be reliably readable.

Given that different readers will prefer different fonts, it makes sense with electronic documents to provide a choice, with the default probably being a sans-serif font in most cases for the reasons explained above. This is, in principle, easy to arrange for web pages because HTML supports alternative style sheets that a user can select, although this facility is less obvious than it used to be because web browsers tend to hide their menu bars by default. For example, in Firefox 47 (and many recent earlier versions), if the menu bar is hidden then press the Alt key, then select the View menu, which shows a Page Style sub-menu. This will show any alternative page styles that are available, which could offer different fonts. With a conventional web site, provision of alternative fonts is at the discretion of the page author, but with a CMS it is at the discretion of the CMS developers, and in my experience CMSes do not offer alternative fonts (or any alternative styles). It is difficult or impossible for a normal user to add this facility, which may make CMSes less accessible than conventional web sites.

Colours

I have learnt from students with some disabilities, in particular dyslexia and Irlen Syndrome (which is often associated with dyslexia), that they may find the choice of colours used in a document, and in particular the contrast difference among document elements, has a bearing on accessibility. Some time ago, we had a student with Irlen Syndrome who wore yellow tinted spectacles and wanted all important documents printed using black ink on yellow paper. I was involved in ensuring that we met his needs; I think at the time I was Senior Tutor for Mathematical Sciences.

Last year, a student taking my module, Introduction to Mathematical Computing, asked me how she could configure Maple to use a coloured background instead of its default white background. I already knew that she was dyslexic; I don't know whether she had any other visual impairments. My immediate reaction was to advise he to use the standard Microsoft Windows accessibility options. (We run Windows on the Queen Mary student service.) However, when I investigated, I discovered that it didn't work with standard Maple. This may be in part because Maple is not specifically a Windows application: the Maple user interface is implemented in Java and is portable across a range of desktop platforms. Or it may be that Maplesoft have not considered accessibility. There is no way to change the background colour of a standard Maple window! However, there is a workaround to this long-standing limitation, which is to embed the content of the Maple worksheet or document within a one-cell table and then change the background colour of the cell. I explained this solution to my student and she found it helpful. Of course, by the time of the final exam, she had forgotten how to do it, so I had to do it for her at the start of the exam.

Semantic markup

Choice of font and background colour does not help non-visual readers, but semantic markup makes electronic documents much more accessible via assistive technology and automated conversion and reprocessing. Semantic markup is using markup that indicates the significance of the content independently of its appearance or graphical display. For example, marking up a section headings as a heading is semantic whereas marking it up as a paragraph using a different font with a bold weight and different spacing is not semantic.

I have learnt from colleagues and students that many people are completely unaware of semantic markup and I regularly find myself translating non-semantic markup written by other people into semantic markup, such as when they provide me with content to go on the web somewhere. I think this is partly a consequence of using only graphical editors, such as Microsoft Word, whereas I find that writing and/or editing HTML source code makes me much more aware of the advantage of semantic markup, since unformatted HTML can be difficult to read, especially if it is non-semantic.

In my view, L^ATEX, described in the book "L^ATEX: A Document Preparation System", 2nd Edition, by Leslie Lamport (Addison-Wesley Professional, 1994), is one of the few document processing systems that really encourages semantic markup, and it did so well before this became a widely used phrase. I learnt a lot about semantic markup fairly early in my career from the first edition of Lamport's seminal book and I would like to quote a few snippets from pages 6 and 7 of the second edition:

L^ATEX is your typographic designer, and TEX is its typesetter.
⋮
For a document to be easy to read, its visual structure must reflect its logical structure.
⋮
The primary function of almost all the L^ATEX commands that you type should be to describe the logical structure of your document. As you are writing your document, you should be concerned with its logical structure, not its visual appearance. The L^ATEX approach to typesetting can therefore be characterized as logical design.

L^ATEX introduced markup for what is generally called an environment that is delimited by explicit beginning and end markers: an environment called name is marked up as \begin{name} … \end{name}. This has huge semantic advantages and is equivalent to the current HTML markup <name> … </name>, whereas in early versions of HTML many closing tags (of the form </name>) were optional, making the markup much less semantic and much harder to parse reliably. Note that the first edition of Lamport's book appeared in 1985, which preceded the World Wide Web by around 5 years and SGML, on which HTML is based, by a year.

HTML supports semantic markup and HTML5 supports it better than earlier versions. For example, the HTML tags <h1> to <h6> support six different levels of heading. Some online HTML editors support headings but some do not, in which case the only way to mark up headings using the appropriate tags is by editing the HTML code. I would argue that HTML editors that do not even support the heading tags actively discourage accessible markup and should probably be banned!

Microsoft Word also supports a range of styles, which are similar to L^ATEX environments or HTML elements. For example, Word supports nine heading styles called Heading 1, Heading 2, … The right way to use both HTML and Word is to focus initially on semantic markup using appropriate tags or styles, and then if necessary to modify the visual appearance of marked-up elements by editing the styles. The wrong way to use Word is to use random applied formatting to make a document look right because this has no semantic content and so is inaccessible and impossible to maintain.

Mathematics

The problem of making mathematics accessible to visually impaired readers is much more difficult than that of making text accessible. Whereas text consists primarily of a linear sequence of characters, mathematical notation is two-dimensional. It can be linearised, but the linearised form may not closely resemble the normal displayed form. Professional mathematicians mostly use TEX or L^ATEX as their preferred way to linearise mathematical notation when typing it, both as input to TEX or L^ATEX processors and in transient documents such as email communications, which is as accessible as any other text provided you understand the language. (L^ATEX is implemented on top of TEX and the syntax for mathematical notation is very similar in both, so for simplicity I will refer only to L^ATEX, which I think is more commonly used these days than plain TEX .)

One of the most common ways for academic mathematicians to publish mathematical documents is as PDF generated from L^ATEX source documents. But a PDF document consists of characters in specific positions on a virtual page and mathematics in such a document is fairly inaccessible. The L^ATEX source document would, in principle, be more accessible. Quite a lot of mathematical notation is inherently ambiguous and its meaning relies heavily on context, which impairs its accessibility (probably even for sighted readers). Most L^ATEX markup is equally ambiguous and using PDF to display mathematics does not help at all. L^ATEX and PDF do not produce accessible mathematics, they just produce visually elegant mathematics. The most semantic mathematical markup currently available in practice is content MathML, but this is not intended to be rendered, so the best approach for all readers is presentation MathML containing embedded content MathML, at least in principle. I pursue this topic a little further and illustrate it in a document I present below as evidence.

A few years ago, we had a visually impaired student and I learnt a lot about displaying maths on the web by converting teaching materials from L^ATEX to XHTML+MathML in the hope that he would be able to access them more easily. (Unfortunately, I could only generate presentation MathML because the semantics to generate content MathML were already lost in the source documents.) I used TeX4ht for this purpose. My conversions were not a success, mainly because the visually impaired student would not work with us to develop teaching materials that he could access. He wanted sighted helpers to work with him rather than support to access information on his own. I learnt from this experience that accessibility is at least partly a sociological problem!

However, from a technical standpoint my conversions were mostly successful because I could open the XHTML+MathML files in Firefox and compare them with the PDF versions. Every so often, I had to correct the MathML by hand, which was an interesting experience! Module notes that contained a lot of images, which I could not convert to anything accessible, were a problem. One of the policy documents that I describe in part (b) below was intended to ensure that suitable source documents would be available for me to convert for such a visually impaired student.

Web accessibility

A useful guide to accessibility of web pages (and web applications) is provided by "A Web for Everyone: Designing Accessible User Experiences" by Sarah Horton, Whitney Quesenbery (Rosenfeld Media, 2014), which asserts that around 10% of people have a disability of some kind. I learnt from reading this book that there is more to producing accessible web documents than just using semantic markup. In particular, screen readers process HTML somewhat differently from the way a graphical browser renders it and a sighted reader reads it.

For example, alt and title attribute values for <img> tags are likely to be much more significant when using a screen reader and it is unhelpful if they duplicate each other. If an image is purely for decoration then it should have an empty alt attribute value (rather than none or a description of the decoration). This is not the impression often given by the way CMSes handle images. This book also recommends not setting hyperlinks to open in a new window by default because it removes the user's choice, breaks the browsing history, and the link may appear to be broken to a visually impaired user if they are not aware that a new window has opened. I had set hyperlinks to open in a new window by default fairly liberally before but I now appreciate that this is a bad idea, so I have stopped doing it and begun changing this behaviour on existing web pages.

Wikipedia, from which I have taken some of the following information, provides a good summary of web accessibility. The key accessibility guidance is that developed by the Web Accessibility Initiative (WAI), a project by the World Wide Web Consortium (W3C). In 1999 the WAI published the Web Content Accessibility Guidelines WCAG 1.0, which it updated in 2008 as WCAG 2.0. Governments are steadily adopting the WCAG 2.0 as the accessibility standard for their own websites. There are three levels of conformance – A, AA and AAA – which are successively more stringent with each including the previous levels and AAA being the most stringent.

In the USA, there is web accessibility legislation known as "Section 508". The current version was enacted in 1998 as the new Section 508 of the Rehabilitation Act of 1973. It requires all Federal agencies when they develop, procure, maintain, or use electronic and information technology to give disabled employees and members of the public access to information that is comparable to the access available to others. The UK government has published new (labelled beta in June 2016) guidance on Helping people to use your [digital] service, which strikes me as a lot weaker than Section 508. It states that "if you exclude anyone from using your service based on disability, you may be in breach of the Equality Act 2010" and "as a minimum, your service must meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.0". According to A Web for Everyone, most accessibility standards are very similar, and it is likely that the next version of Section 508 and future EU accessibility regulations will be based on WCAG 2.0 Level AA.

An important and interesting technical development is the WAI Accessible Rich Internet Applications (WAI-ARIA) standard, which defines enhanced semantic markup in the form of HTML attributes intended primarily to make actionable elements accessible to people using assistive technology. For example, the WAI-ARIA "role" attribute values (application, banner, complementary, contentinfo, form, main, navigation, search) are intended to group and label sectioning markup. The “aria-expanded” attribute can be set programmatically to “true” or “false” to indicate the state of a widget such as an accordion. Fortunately, JavaScript libraries such as jQuery already include appropriate WAI-ARIA markup. Unfortunately, no CMS that I have used provides any encouragement to add WAI-ARIA markup or adds any automatically to user-provided content.

NVDA (Non Visual Desktop Access) is an open-source screen reader for Windows that provides excellent support for WAI-ARIA. The blog article entitled Meaningful CSS: Style Like You Mean It discusses some more technical aspects of semantic markup and how to make styling more semantic by taking advantage of HTML5 and WAI-ARIA. Accessibility in the browser by Cassidy Williams is a useful video that provides a look at the Accessible Rich Internet Applications specification (ARIA), which enables dynamic applications to work with a variety of assistive technologies.

Evidence

In 2010, I developed a Policy on Undergraduate Teaching Materials that specifically refers to our obligations under the Disability Discrimination Act. In September 2015, I moved this document from our old intranet (a broken Dreamweaver web site) to our new intranet (a QMplus course area) and in the process updated it (trivially). Because the current version exists only as an HTML document on our intranet, which is not publicly accessible, the above link is to a version I have printed to PDF using the QMplus "zoom in" facility to avoid extraneous information.

I learnt from a long-running debate with a couple of colleagues (who have since retired) that people can feel very strongly that serif fonts are best. I therefore offered a serif font as a alternative to my default choice of a sans-serif font for a couple of documents providing details of all School of Mathematical Sciences modules when I maintained this information as conventional web pages. Since moving to a CMS (QMplus) I no longer do this because it would not be so easy and there no longer seems to be any demand. For details of how this worked, please click on the tab labelled "Font selection" in the School of Mathematical Sciences modules 2013–14. Note that I only provided font selection for two of the documents: A summary of overlaps, prerequisites, and other restrictions and Full details of all our modules in one HTML document.

A screen shot of a student's Maple exam answer with a green background shows how I accommodated the accessibility needs of a dyslexic student last year (2015).

I have written the web document "Accessibility and Ambiguities of Mathematical Notation and Markup" to illustrate some of the points I made above. It uses MathJax (in its default configuration) to render the mathematics. The link I have provided downloads this document as a separate file. I can't embed it in QMplus Hub as I would like to because it also uses MathML, which QMplus Hub silently removes, regardless of exactly how I embed it. I have no idea why this happens, but it highlights the difficulties of publishing mathematics on the web. QMplus Hub claims to serve HTML5 documents and MathML is valid HTML5. (However, so is JavaScript, but that is also silently removed by QMplus Hub!) It is possible that this mathematical web document will not be rendered correctly by all browsers on all platforms, so to show unambiguously what it should look like I have used Firefox to print it to PDF and also included the PDF version in this portfolio.

No links in the document you are currently reading (my CMALT ePortfolio) should open in a new window by default (unless I have missed some I created early on) and the links on the School of Mathematical Sciences QMplus landing page and the School of Mathematical Sciences Undergraduate Student handbook no longer open in a new window by default (whereas they did in previous versions).

Description and Reflection

Once the School of Mathematical Sciences began to use QMplus for all its modules, I felt that we needed some guidelines that would help to ensure that usage was reasonably consistent. I wrote a draft document that we discussed at a Teaching and Learning Committee meeting in May 2014. Based on feedback from that meeting, I revised the document and produced a final version dated 1 August 2014. I put the document on our staff intranet and circulated the URL to staff.

In my policy document for QMplus module pages, I distinguished two types of content that I called formal and academic. I used the term "formal content" to refer to features that should be present for every module, such as information about the module organiser, syllabus, learning outcomes, etc. Most of this is set up and maintained centrally. Initially, this meant by me, but I am in the process of handing some responsibility for maintaining the formal content over to Professional Services colleagues, in particular our Undergraduate Programme Administrator. I used the term "academic content" to refer to teaching materials that would normally be created and/or maintained by the current module organiser.

The document ends with a very brief strategy section, which was more of a place holder than a serious strategy. I'm pleased to see that I have accomplished most of the three key strategy points that I listed in 2014. The point that still needs some work, and probably always will, is to improve consistency further. It was my expectation that I would revise this document again fairly soon although I have not yet done so. Our E-learning Unit is now in the process of developing a new e-learning strategy for the whole of Queen Mary, part of which is that Schools should also develop their own consistent strategies. I have provided some comments on the current Queen Mary draft, but there is not much point thinking seriously about revising our School strategy until the Queen Mary strategy has been agreed. It is likely to include a template for Schools to follow.

Policy documents like this need revising fairly frequently because the target moves and QMplus is evolving. In a footnote to our current School guidelines I referred to docking of Moodle blocks no longer being possible and an expectation that this would be fixed soon. That is no longer my expectation. I presume that the facility for docking blocks has been superseded by the facility to "zoom in" on the central content area, which happens automatically on smaller displays as part of the "responsive design" that was added fairly recently. So I will need to replace references to docking blocks with the suggestion to use the "zoom in" button when I revise this document.

A problem that I always spend a lot of time grappling with when developing any kind of policy document is deciding how prescriptive it should be. I don't want to state that staff must use facility X only to find that facility X is removed, replaced or significantly revised following the next software upgrade! In order to retain credibility, a policy document has to be flexible enough to accommodate such changes in the system to which the policy relates. I have also learnt from observing my colleagues' reactions over many years that they don't like to be told what to do, and often the only way to get a policy agreed at all is to express much of it as guidelines and recommendations rather than as firm policy. This is why our current QMplus policy document is actually entitled "QMplus Guidelines and Strategy".

One thing our current QMplus policy document does not mention is our School policy to make most of our module information publicly accessible. I probably didn't include this because it was what staff expected and so was not contentious, but it should be included when the policy is next revised. Nevertheless, open access involved quite a lot of negotiation when the School moved over to QMplus and it seems to be a somewhat unusual way to use a VLE. Other Schools at Queen Mary, especially in our Faculty of Humanities and Social Sciences, keep most of their information password-protected, which means that neither I nor my students can access it. I think this insistence on closed access is because these Schools' first use of the web was via a VLE rather than a conventional web site.

Previously in the School of Mathematical Sciences we published all our teaching materials on our web site and there was never any thought of restricting access. I think that was partly because there was no easy way for individual module organisers to do it. But we were (and still are) happy for our teaching materials to be freely available (in most cases) because it provides good publicity and allows prospective students to see what we provide. By contrast to a conventional web site, VLEs control access and require users to log in, and I don't think that guest access to QMplus was initially possible. Together with colleagues in one or two other Science & Engineering Schools, Physics in particular, I remember arguing the case for making guest access available. Currently, we have the option of allowing guest access to a QMplus page or not, and I think this has been the case ever since the School began mainstream use of QMplus.

Our access policy is that all of our undergraduate teaching materials are publicly available, which means that they can be accessed by guest users who are not required to log in. Our teaching materials for modules used only in our high-fee MSc in Mathematical Finance are closed access since students pay a premium for this programme. Our landing page, student support and generic information page are all publicly accessible. Until recently, we had one other generic information page that was not publicly accessible, which in fact was the first page I set up by migrating the content from Queen Mary's previous VLE, Blackboard. Now all our generic information pages are open-access but I allow only logged-in users to access a few resources. (I discovered very recently a way to do this by restricting access to users with a non-empty user id in their profile, which seems to work.)

I restrict access to a small amount of information that we cannot release publicly, such as how students can install Maple for free on their own computers, and an e-book version of a module textbook written by one of my colleagues that is commercially published. I have progressively made more information public. My original policy was not to make information publicly available if I felt it would only be of interest to current students but I have now changed to a more flexible policy of making information publicly available unless there is some very good reason not to, such as a legal or commercial reason.

A policy matter that I am currently working on is the School of Mathematical Sciences Q-Review Policy and Guidelines. Q-Review is the Queen Mary lecture capture system (currently using Echo360). Lecture capture is generally popular with students but not with staff. Q-Review has been available for at least four years but has not been used much by the School of Mathematical Sciences until this year. One concern staff have is that if students know that a lecture will be recorded they will skip the lecture with the intention of watching the recording later, whereas the recording should be used as backup, such as for when a student has to miss a lecture for a good reason, or for revision.

A specific concern for Mathematical Sciences staff is that many prefer to lecture by developing their mathematical argument on a blackboard, or failing that a whiteboard, which requires writing a lot of detailed mathematical notation during a lecture. This is not captured in any very useful way when a lecture is recorded, at least not by our current lecture capture system. Staff take the view that this makes recording lectures pointless, especially since we normally provide detailed, often typeset, module notes in QMplus. Students claim that they like to listen to a lecture whilst following their own lecture notes and/or the notes from QMplus, although staff generally remain unconvinced about the value of this.

In the hope of improving student satisfaction generally, the School of Mathematical Sciences management were keen for Q-Review to be used as widely as possible. About a year ago, there was discussion about making the whole Science and Engineering Faculty a "Q-Review Faculty", meaning that lectures would be recorded by default, but Schools or individual lecturers could opt out. Our Director of Taught Programmes, our Education Manager and I all believed that it had been decided last summer that Science and Engineering would be a Q-Review Faculty from this academic year, on the basis of which our Teaching and Learning Committee agreed that Mathematical Sciences would be a Q-Review School from this academic year. Therefore, I added a "Q-Review Block" to all our QMplus module pages. We then discovered that it had not been agreed that Science and Engineering would be a Q-Review Faculty, so we had to drop our proposed policy to be a Q-Review School. In view of the lack of enthusiasm from staff we felt that we did not have enough Queen Mary support.

It was finally agreed very late in the autumn semester that Science and Engineering would be a Q-Review Faculty from the spring semester, so we took the opportunity to become a Q-Review School. At our Teaching and Learning Committee meeting in March I was asked to develop a Q-Review Policy and Guidelines to try to codify some of the information we had gleaned so far about how we could and should use Q-Review. I wrote a first version of this document by selecting information that I thought was most relevant from the fairly large amount already provided on the web by our E-learning Unit. I tried to focus on issues that I knew were of concern to my colleagues and my first draft had as part of our policy that staff should check that their lecture recordings were "fit for purpose".

However, our Teaching and Learning Committee took the view that this was not the job of the lecturer and that it should be the students' responsibility to complain promptly if a lecture recording was not fit for purpose. In my third and current draft, I moved the paragraph about checking recordings from the policy to the guidelines and changed it significantly so as effectively not to require lecturers to take any responsibility at all. The review period expired and I had no further comments, so my latest draft has become our policy and I have put it on our staff intranet and notified all staff.

Evidence

I normally write policy documents initially in Microsoft Word, which I then export or print to PDF so that I can circulate the document to a small group of people for discussion, usually before, during and/or after some committee meeting. Relatively few of my colleagues in the School of Mathematical Sciences use Windows (most prefer Linux), so they tend not to have access to Microsoft Word or a reliable alternative that will open Word documents. I therefore normally circulate documents as PDF, which colleagues using other platforms can open reliably. However, I prefer to use HTML for documents on the web unless there is very good reason not to. For documents that I write, I have the source version in Microsoft Word, which I convert to HTML. This means it will subsequently be easy for anybody with appropriate access to edit the version in QMplus without having to deal with the problem of editing a PDF file without access to the source document! I provide my final PDF versions of two policy documents below since the HTML versions are on our intranet, which is not publicly accessible.

• QMplus Guidelines and Strategy (Francis Wright, August 2014)
• Q-Review Policy and Guidelines (Francis Wright, May 2016)