Recently I was asked to present at the Media-Enhanced Learning Special Interest Group (MELSIG) event hosted by the University of Sussex. MELSIG is a special interest group originally formed in 2008 (MELSIG, 2014). The group’s focus has evolved, alongside contemporary developments in technology, to include investigation of a wide variety of digital media when applied to the support of learning and teaching. The theme for the University of Sussex event was Digital Media Interaction and Inclusivity and this was exactly the prompt I needed to engage in more thorough research of in-app adjustment functions which has been preoccupation of mine for a while.
Embedded Nearpod Presentation from MELSIG event
Through my work building ‘communities of practice’ (Wenger, 1998) on both sides of the Atlantic, and in particular during the development of App Swap events at the University of Brighton something always bothered me about apps or mobile applications/software. Namely why, when developers have such rich SDKs to work with, isn’t there more attention to paid to inclusivity when designing apps? Both the iOS and Android operating systems have a number of built-in functions which have the potential to greatly aid accessibility in addition to the benefits afforded by the touchscreens and the form factors of the devices themselves. However, due to the unique conditions under which apps are developed a combination of factors including time/monetary constraints, corporate interests and the lack of a common accessibility guidelines seem to stifle the potential of certain apps on the accessibility front. Indeed within app development no equivalent to the WC3’s Web Accessibility Initiative seems to have emerged and the rule systems applied to website design such as the EU Internet Handbook have no bearing on the design of apps. On the one hand this is quite liberating for interface designers and has led to something of a Wild West populated by some truly innovative interface designs.
My intention with this post, I should point out, is not to stifle innovation, but rather I would like to propose that when an app’s primary purpose falls within certain categories of use, ‘categories’ which can be applied to the creation or consumption of educational materials or be used in support of learning, that extra attention be paid to the accessibility features of ‘said’ apps. Perhaps in the future this could resemble a set of agreed standards, but at this time I would like to make more of a humble request rather than a full recommendation. The core idea I put forth in relation to my ‘request’ is the notion of letting the user choose and customise the app through the presence of ‘adjustment’; this I believe is a key facet of the path to accessibility. I shall expand on ‘categories of use’ later in this post.
A personal experience which prompted this line of enquiry was my use of Amazon’s Kindle app for iPad. In October 2011 Apple introduced support of text-to-speech (TTS) within their iOS5 operating system (Moren, D. 2012); as a Dyslexic person I was eager to make use of this function and to this day find it immensely useful. Imagine my disappointment to find out that the ‘Speak Selection’ tool is actively blocked within the Kindle app. The ‘VoiceOver’ tool was later allowed within the Kindle for iPad app (Ingber, J. 2013) and Amazon had introduced its own text-to-speech function to the Kindle 2 device in 2009 but eBook publishers could choose to disallow the function with the viewpoint that it might damage audiobook sales (Schofield, J. 2009). There is another aspect of the Kindle app which always seems a bit of an oversight; reading background colours. Given the development resources available to Amazon, there are only three options provided for the text background colour: White, Black (X-Ray) and Sepia. Why not make the reading experience as accessible as possible by including customisable background colours as evidenced by apps like Bluefire Reader, Kobo Reader and Goodreader? When comparing Kindle to particularly Kobo reader and Goodreader one is reminded of the oft used technological paradigm of VHS and Betamax; VHS won due to market share in combination with other factors rather than viewing quality.
So why the title of The Adjustment Bureau? The 2011 film, The Adjustment Bureau based on the Phillip K. Dick’s short story, The Adjustment Team (1954 – full text) which tells of characters whose life choices deviate from a preordained plan set-out by a mysterious organisation. Inspired by this idea I postulated that there may be a parallel between that concept and app developers whose choices are guided or pushed by a combination of external factors and client influences, ultimately I wondered whether this explains why the avenues to accessibility are so seldom followed? With all of this in mind I decided to enter into an assessment of the adjustment functionality available within some of the most prominent and popular apps I have encountered while working in Higher Education. I focused on apps available for iOS for this pursuit as that is the primary device type supported in my workplace and I had access to the devices. This also prompted me to define some basic ‘categories of use’ when applied to app use within academia for the support of learning and teaching.
The Categories of Use are as follows:
|Browser||A web browser for navigating web-based information. May include other features such as reader functions and RSS curation.|
|Composer||In this context for the composition of text-based materials and documents.|
|Consumer||For curation and consumption of RSS content, blogs and online news sources.|
|Notetaker/annotation||Apps with the main purpose of taking notes and/or placing notes and annotation on documents.|
|Reader||Apps with the primary purpose of reading text, eBooks, ePubs, PDF and other text formats. May have limited annotation tools.|
When defining the categories I tried to resist the use of pre-existing desktop software definitions such as for example ‘word processing’. These definitions have established associations and many apps reach beyond the format-based outputs which are expected from these former software definitions.
The Adjustment Criteria upon which each app was judged are listed below. If an app includes a feature it is awarded a point for that criterion, it may partially allow a feature which would result in a 0.5 of a point. The total score is a point value out of a total of 8, for the 8 criteria and is shown as a final percentage. Apps which achieve >=60% are highlighted in purple.
|Font Size||Font size can be changed specifically, within the app. In the case of ‘composer’ categorised apps this is included in their writing functionality.|
|Line Height||Line height can be changed specifically, within the app. In the case of ‘composer’ categorised apps this is included in their writing functionality.|
|Font Style||Font style can be changed specifically, within the app. In the case of ‘composer’ categorised apps this is included in their writing functionality.|
|Background Colour: Invert/Brightness||Brightness of the display or invert (white text on black background) is a specific option within the app.|
|Background Colour: Sepia||A sepia background (beige/mild yellow) is a specific option within the app.|
|Background Colour: Sliders/Colour||A selection of colours or Red/Green/Blue sliders allow the user to adjust and specify the background colour within the app.|
|Pinch zoom||The pinch zoom is a built-in function of the iOS. Some apps do not make/allow full use of this touch-based function.|
|iOS Speak Selection||A function which can be enabled in the General > Accessibility functions in the iOS this can be used by selecting text in certain apps and pressing the ‘speak’ option which comes up. This is distinct from the ‘Voiceover’ option which is a complete audio interface and harder use for quick impromptu needs.|
The scores as an embedded Google Spreadsheet – a work in progress. NB: this list is not designed to be exhaustive and if you have other apps which you would like me to assess using these criteria, please add them to the comments area below. The “+” next to the app title identifies that the app is available for both iPhone and iPad.
Through this process of investigation and app functionality testing I feel that I have only begun to scrape the surface of how accessibility functions are implemented and the possible avenues for improvement. I think that there is certainly scope to devise a more concrete scoring and testing system with the view to helping teachers and learners make informed decisions about the accessibility functions of certain apps. Such a system would also have the potential to help inform developers about the needs of specific user groups. However the responsibility cannot be squarely that of the developers, as users we also have a responsibility to let developers know what we want and need. One of the benefits of working with apps is that developers are often small to medium sized companies and really benefit from the suggestions from their user-base, this may extend to use testing. In the Wild West of apps we as the user have an opportunity to make a difference and we shouldn’t miss out by sticking to the easy path.
Appendix I – Some particularly successful adjustment interfaces discovered as a result of this investigation
Mercury Web Browser (discussed during MELSIG presentation)
Apple Inc., Accessibility Programming Guide for iOS: Introduction [Online]. Available: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Introduction/Introduction.html [Accessed 23/08/14].
Bluefire. 2014. Bluefire Reader Apps [Online]. Available: http://www.bluefirereader.com/ [Accessed 07/09/14].
Coyle, B. 1995. USE OF FILTERS TO TREAT VISUAL-PERCEPTION PROBLEM CREATES ADHERENTS AND SKEPTICS. Canadian Medical Association journal, 152, 749-750.
Dredge, S. 2011. Top 10 steps towards making your mobile apps more accessible [Online]. theguardian.com. Available: http://www.theguardian.com/smart-accessibility/making-your-mobile-apps-more-accessible [Accessed 23/08/14].
European Commission. 2014. Information Providers Guide – The EU Internet Handbook [Online]. Available: http://ec.europa.eu/ipg/standards/accessibility/index_en.htm [Accessed 07/09/14].
Good.iWare. 2014. Goodreader [Online]. Available: http://www.goodiware.com/ [Accessed 07/09/14].
Ingber, J. 2013. Using VoiceOver with the Accessible Amazon iOS Kindle App. AFB AccessWorld Magazine, 14.
Kobo. 2014. eReading Apps – Kobo [Online]. Available: http://www.kobo.com/apps [Accessed 07/09/14].
Lawrence, J. 2008. Research into Meares-Irlen syndrome. Sutton: Reed Business Information UK.
Lewis, T. 2014. Paddy Considine: ‘I was always portrayed as angry, but I was just ill’ [Online]. theguardian.com. Available: http://www.theguardian.com/film/2014/sep/07/paddy-considine-actor-i-was-portrayed-angry-i-was-just-ill [Accessed 07/09/14].
MELSIG. 2014. About MELSIG [Online]. Available: http://melsig.shu.ac.uk/?page_id=2 [Accessed 07/09/14].
MELSIG. 2014. Digital Media Interaction and Inclusivity [Online]. Available: http://melsig.shu.ac.uk/?page_id=645 [Accessed 07/09/14].
Microsoft. Guidelines for designing accessible apps – Windows app development [Online]. Available: http://msdn.microsoft.com/en-GB/library/windows/apps/hh700407.aspx [Accessed 23/08/14].
Moren, D. 2012. iOS 5 Review: Ambitious update rings in the changes [Online]. macworld.com. Available: http://www.macworld.com/article/1162962/ios_5_review_ambitious_update_rings_in_the_changes.html [Accessed 07/09/14].
Ritchie, S. J., Della Sala, S. & McIntosh, R. D. 2011. Irlen colored overlays do not alleviate reading difficulties. Pediatrics, 128, e932-E938.
Schofield, J. 2009. Amazon caves to Authors Guild over Kindle’s text-to-speech reading. The Guardian Technology Blog [Online]. Available from: http://www.theguardian.com/technology/blog/2009/mar/01/authors-guild-blocks-kindle-voice [Accessed 07/09/14].
World Wide Web Consortium (WC3). 2014. Web Accessibility initiative (WAI) [Online]. Available: http://www.w3.org/WAI/ [Accessed 7/9/14].
Wenger, E. 1998. Communities of practice: learning, meaning, and identity, Cambridge, Cambridge University Press.
Wikipedia. 2014. Software development kit [Online]. Available: http://en.wikipedia.org/wiki/Software_development_kit [Accessed 07/09/14].