For a few years now I have begun thinking about why right now we hear - more often – talking about accessibility in relation to apps and websites, as if it had finally become a social issue. How, after the fight against architectural barriers, for sidewalks with slides, for reserved parking lots, finally it was the turn of all web and mobile users to be able to enjoy digital content and use services, buy products online, with the same simplicity (well, we wish it was always true for everyone) of every user with every sense, every motor and cognitive ability.
Yes, accessibility, not just access in the sense of login or availability of websites and apps as some believe to understand, but of the right of all users, even the less fortunate, those who for various reasons, more or less evident, have difficulties to use a PC or a smartphone, a website or an app. In English, they use the term impaired, perhaps because in our country we still have some difficulties in accepting diversity and disabilities and therefore we adopt Englishisms to sweeten the concept.
There are several disabilities that can compromise the correct use of digital content (ah! to impair means to compromise). We are probably too used to thinking about reduced or absent visual abilities, but the range of cases is very varied by organ and by age. They can vary from the eyes, to the use of hands, to the ability to read, understand and memorize the text, to move and guide the mouse, to listen, to the use of any limb, to the use or non-use of the voice, to the ability to express oneself ... we would probably find a topic for each chapter of Gray's Anatomy (yes, the name of the TV series that challenges the record of Beautiful is a pun on the most famous Anatomy Manual of the late 19th century Still used today in medical classrooms).
Well, we are therefore talking about neuro-psycho-motor difficulties that have probably existed since...ever...which impact 15% of the world population according to the estimates of the United Nations and the WHO, and about digital content and electronic functions such as using a PC, a phone that later became smart (perhaps), a call centre, an voice-mail, an app, an e-commerce, a chatbot, a virtual assistant, 3D viewers, VR, AR. I have a passion for maths: all these gadgets and these beautiful things with which we were born and raised, making our life easy, smart, cheerful, fast etc., have a target of 85 people out of 100 ($ and availability permitting)?
Here, luckily, it is not always like this, and it has not always been like this. There are many buts and many ifs, but everything would become easier if each one of us in our work, in our daily life, wondered what at least one of that 15% would do.
I can tell you what happened since the web, and then the mobile, have taken hold, how some enlightened people have equipped themselves very well, and how I lived this journey that begins with the story I'm about to tell you and arrives to the present day.
The end of 90s and the W3C
In reality, since the spread of the WWW and with the creation of the first websites strictly for viewing in black and white or monochrome, and with a 33K modem, and woe betide if there would been a picture, you would have spent a whole afternoon there ... The consortium W3C had issued a series of guidelines that, in addition to allowing access to the WWW globally without distinction of hardware, software, place, language and computer skills, recommended special attention to categories with visual, hearing, cognitive and motor disabilities.
The message was clear: the web is inclusive. Remember this term, we will come back to it much later. There was great attention in the description of the images (alt-text), in the possibility of being able to move between the forms even without the mouse, perhaps with the tab giving an order to the fields (tab-order).
The first screen reader market tools are born, simple TTS (text-to-speech) or speech synthesizers, able to read the user what appeared on the video and to suggest what the information was and what the possible actions he could perform were, simply by pressing the bar. If you want to try this dialogue in the dark with the UNGUESS website, you can find it here JAWS.
Meanwhile in Italy, for a change, we are not just watching. At the beginning of 2004, among the first in Europe, on the proposal of the then Minister of Innovation and Technological Infrastructure Lucio Stanca, the law bearing his name was published, which imposes the Accessibility requirement as indicated by the W3C to all websites of the Public Administration, companies connected with public services, including the IT companies that collaborate with them, public transport companies, health care companies etc.
Today AGID deals with it with a procedure that requires the introduction of accessibility for mobile apps and workstations for workers with disabilities. Furthermore, it introduces the subjective evaluation of the initiatives to be carried out (with respect to the costs-benefits on public finance) with the stakeholders, a moderator, focus groups according to the contexts and the type of users to be involved. After the declaration of accessibility, the certified body can use the badge issued by the certifying body.
Even in the large UNGUESS community, we were able to conduct tests under particular conditions and with very enthusiastic users to conduct an accessibility task. Sometimes it is not just the Public Administrations that do it "by law", but, as we said before, there are product and service companies that now can’t no longer neglect that 15% of their customers and turn away.
# 1 - The content must be PERCEPTIBLE
Even if a user has visual impairments or hearing difficulties, the contents and functional elements must be clear and usable. This involves a whole series of strategies that include colour contrast, font sizing and the obligation to enter an accurate and descriptive Alt-text.
# 2 - The content must be OPERABLE
Can a user operate and navigate through the website? Not everyone can use a mouse! There must be other ways to use the website (e.g. keys or voice). The important information should be shown slowly and when needed, as some cognitive impairments can significantly slow reading comprehension. Dyslexia also makes it difficult to use the WEB and apps.
# 3 - The content must be UNDERSTANDABLE
Is the page content organized and presented in a way that avoids confusion? Is the website structured in a predictable and consistent way? Do you use clear language? Users may have different cognitive and visual abilities, due to either a physical ailment or a lack of education in rural areas.
# 4 - The content must be ROBUST
The most accessible websites are those built with HTML, CSS and JS, in a way that are compatible with the greatest number of browsers and that can work with the vast majority of assistive tools. Knowledge of future technology, as well as outdated tools that some users may still be using, is always important to consider.
My inner Nerd claims his share. I show you what it means for a developer to "fulfill" these requirements. I actually do this because this moment and how things went from there made us reach the 2020s with all these apps and websites that have little about accessibility. Indeed some websites are not even cross browsers, or cross smartphone. Some apps or Operating System too. UNGUESS take care of it!
(source / inspiration html.it)
Segregate the presentation of a document from its content: this means that, on one hand, it is necessary to avoid inserting presentation constraints in the (X) HTML code, on the other hand it is necessary to use CSS to define the formatting of the document and its possible presentation for other media (print, speech synthesizers, mobile, TV, etc.)
Use the strict Dtd of XHTML 1.0 or, alternatively, the Dtd of XHTML 1.1: they are the most suitable to achieve the purpose of segregating the presentation from the content
Do not entrust any information solely to the use of colour
Highlight the logical structure of the textual content, by using in the most appropriate way the appropriate elements and structural attributes of (X) HTML
Create accessible forms, by using the appropriate elements and attributes - FIELDSET, LABEL, etc. - and CSS to make the various fields more visible on the page (and possibly zoomable at the user's discretion)
Make the data tables accessible, by using the appropriate structural elements and attributes provided starting from HTML 4: CAPTION, TH, COL, COLGROUP, summary, scope, headers, ID, etc.
Replace tables used for layout purposes with CSS-based solutions. If anyway you decide to use layout tables, possibly avoid nesting multiple tables into each other and, above all, formatting the cells using (X) HTML presentation elements and attributes. Instead, use CSS for their formatting and, especially, make sure that the content of each layout table is linearized correctly, if read in non-graphic mode.
Write alt-text that performs an equivalent function to the non-textual content that they replace.
Write accessible texts, which emphasize the simplicity, correctness and adequacy of the language, and at the same time avoid the distortions and incomprehensibilities of the advertising, technical and bureaucratic style.
Do not use frames. There are other more accessible ways of building a navigation interface.
Create pages whose contents remain accessible in the disparate conditions of use, rather than pages that are seen in the same way on all major graphic browsers and devices: that is, free yourself from the "prejudice of the press".
Write pages based on valid (X) HTML and CSS code
Use automated tools to detect code-related accessibility errors.
Use human review to check the accessibility of all elements of the page that cannot be checked automatically (text properties and correctness, comprehensibility of the navigation mechanisms, foreground / background contrast, etc.).
Set yourself the goal of achieving real accessibility, verified by tests and feedback with human individuals, rather than the sterile display of compliance label.
Io personalmente concordo sugli ultimissimi punti, non me ne vogliano i dev, sono stato sviluppatore anche io, ma pensare come e dove verrà visualizzato un contenuto o dovrà essere compilato un form la dice lunga su come dovrete scegliere i componenti migliori, il codice corretto e poi i test da fare, quali fare, a chi farli fare, e l’utente prima di tutto, al centro. Piuttosto che il bollino.
I personally agree with the very last points. No offences to the “devs”, I have been a developer too, but thinking about how and where a content will be displayed or a form will have to be filled in, says a lot about how you will have to choose the best components, the correct code and then the tests (which ones, who is going to do them). Let's just say we should remember to put the user at the centre, rather than the label.
Click here to read chapter 2 of Accessibility right or duty?