.<\/p>\n\n\n\n
What does accessibility mean?<\/strong><\/h2>\n\n\n\n\u201cPutting the web and its services available to all individuals, whatever their hardware, software, network infrastructure, mother tongue, culture, geographical location and their physical or mental capacities.\u201d Definition of accessibility attributed to Tim Berners-Lee.<\/p>\n\n\n\n
Anyone can find themselves in a situation of permanent, temporary or situational disability. A broken arm, the brightness of sun outside or a degenerative disease such as Parkinson’s can lead to an impairment.<\/p>\n\n\n\n
Developing an accessible application means making sure not to exclude people.<\/p>\n\n\n\n
Accessibility is defined by an international standard (Web Content Accessibility Guidelines<\/a>) as well as national standard (R\u00e9f\u00e9rentiel G\u00e9n\u00e9ral d’Am\u00e9lioration de l’Accessibilit\u00e9<\/a>) and an ISO standard (ISO\/IEC 40500:2012<\/a>).<\/p>\n\n\n\nAccording to these, an application is accessible if it meets the following criteria:<\/p>\n\n\n\n
- Perceivable<\/strong>: Information and user interface components must be presented to users in ways they can perceive.<\/li>
- Operable<\/strong>: User interface components and navigation must be operable.<\/li>
- Understandable<\/strong>: Information and the operation of the user interface must be understandable.<\/li>
- Robust<\/strong>: Content must be robust enough so that it can be interpreted reliably by a wide variety of user agents, including assistive technologies (screen readers, for instance).<\/li><\/ul>\n\n\n\n
.<\/p>\n\n\n\n
Accessibility regulations<\/strong><\/h2>\n\n\n\nIn Europe and the UK, accessibility is a legal requirement covered by generic laws (the Equality Act 2010<\/a> and the European Accessibility Act<\/a>). Digital-specific accessibility legislation exists but it is currently mostly limited to public sector organisations, although there are variations from country to country. In France, for instance, the law applies to both public sector organisations and large private companies and failure to comply can result in hefty fines. Whether required by a specific law or covered by a generic law, WACG guidelines<\/a> are the standard to follow for any organisation seeking to become accessibility compliant.<\/p>\n\n\n\nWhile legislation is useful in forcing organisations to be accessibility compliant, what could speed things up is the threat of legal action of the ilk we are seeing in the US, as with Domino\u2019s Pizza<\/a>. In 2018, the number of federal website accessibility lawsuits nearly tripled.<\/a><\/p>\n\n\n\nNotwithstanding, digital accessibility is not just about legislation. It\u2019s an open, buoyant and innovative market worth looking into. The European Commission estimates that<\/a> 5% of people in the EU does not use the internet because of some disability and just 10% of websites in Europe is accessible for persons with a disability. Accessibility is also important for the elderly \u2013 who account for 19.2% of the EU population \u2013 as well as people who are temporarily affected by an impairment (broken wrist, lost eyeglasses, eye disease, etc.).<\/p>\n\n\n\nThis W3C article from the Accessibility initiative<\/a> makes the business case for accessibility, exploring how accessibility can boost innovation, image and market share. Everyone can benefit from digital inclusion. <\/p>\n\n\n\n.<\/p>\n\n\n\n
Developing an accessible webmail app<\/strong><\/h2>\n\n\n\nEmail is the no1 enterprise tool. It must therefore be accessible to all, which is why building a new webmail was such a crucial project for BlueMind. For it to be relevant and well-integrated, the issue of accessibility must be addressed from the very inception of any app and infuse every stage of development. <\/p>\n\n\n\n
Training<\/em><\/strong><\/h4>\n\n\n\nAt BlueMind, all webmail and UX developers are trained in accessibility issues and standards.<\/p>\n\n\n\n
Design<\/em><\/strong><\/h4>\n\n\n\nAccessibility is built into the app\u2019s features from the very beginning of the design stage. Here are a few questions our team typically asks itself at the mock-up and specifications stage. <\/p>\n\n\n\n
- Can all the buttons be used from the keyboard?<\/li>
- When the app is used with a screen reader, do all the icon buttons have a text description?<\/li><\/ul>\n\n\n\n
![\"\"](\"https:\/\/bluemind.purpl-web.com\/wp-content\/uploads\/2021\/04\/icone-attention.png\")
<\/figure><\/div>\n\n\n\n- Is all the information visible for colour blind people? For example, an error message in red will be more clearly visible if it comes with an icon:<\/li><\/ul>\n\n\n\n
![\"\"](\"https:\/\/bluemind.purpl-web.com\/wp-content\/uploads\/2021\/04\/tooltips-small-1024x151.png\")
The webmail is also fully available in english, captions are in french for conveniency<\/figcaption><\/figure><\/div>\n\n\n\nDevelopment<\/em><\/strong><\/h4>\n\n\n\nIn the development stage, the team uses a whole set of accessibility assessment tools (Google Lighthouse<\/a>, Axe<\/a>, WAVE<\/a>, etc.).<\/p>\n\n\n\nTesting<\/em><\/strong><\/h4>\n\n\n\nThe trial phase is key for any software publisher. Testing accessibility is no small feat as only about 30% of accessibility issues can be detected automatically.<\/p>\n\n\n\n![\"\"](\"https:\/\/bluemind.purpl-web.com\/wp-content\/uploads\/2021\/04\/phase-de-test-hd-1024x243.png\")
<\/figure>\n\n\n\nThe app therefore has to be tested manually after implementation is complete. A great way to do this is to learn to use a screen reader such as NVDA<\/a> or ORCA<\/a>. This type of software isn\u2019t easy to get a hang of, but it is by putting yourself in a difficult situation that you are better able to understand your user. More simply, you can also test your application using a keyboard alone. The BlueMind website is fully keyboard accessible too: give it a try by leaving this article and moving to another page using your keyboard only.<\/p>\n\n\n\nSome browser plugins can also be used to test issues to do with visual impairments. Below is a colourless version of BlueMind (for achromatopsia<\/a> sufferers) using the NoCoffee<\/a> vision simulator for Chrome.<\/p>\n\n\n\n.<\/p>\n\n\n\n![\"\"](\"https:\/\/bluemind.purpl-web.com\/wp-content\/uploads\/2021\/04\/webmail-nb.png\")
<\/figure>\n\n\n\nHello black and white webmail!<\/p>\n\n\n\n
.<\/p>\n\n\n\n
Capitalising<\/em><\/strong><\/h4>\n\n\n\nCapitalising on existing, consistent resources is key in ensuring first-class software development.<\/p>\n\n\n\n
Our repository of graphic components (available here: https:\/\/forge.bluemind.net\/staging\/styleguide\/abm-styleguide.html<\/a>) includes a best practices guide and a library of components that can be reused by all the actors of our solution. This also enables us to provide the best user experience possible<\/a>, both for browser and mobile usage.<\/p>\n\n\n\nConclusion<\/strong><\/h2>\n\n\n\n
According to these, an application is accessible if it meets the following criteria:<\/p>\n\n\n\n
- Perceivable<\/strong>: Information and user interface components must be presented to users in ways they can perceive.<\/li>
- Operable<\/strong>: User interface components and navigation must be operable.<\/li>
- Understandable<\/strong>: Information and the operation of the user interface must be understandable.<\/li>
- Robust<\/strong>: Content must be robust enough so that it can be interpreted reliably by a wide variety of user agents, including assistive technologies (screen readers, for instance).<\/li><\/ul>\n\n\n\n
.<\/p>\n\n\n\n
Accessibility regulations<\/strong><\/h2>\n\n\n\n
In Europe and the UK, accessibility is a legal requirement covered by generic laws (the Equality Act 2010<\/a> and the European Accessibility Act<\/a>). Digital-specific accessibility legislation exists but it is currently mostly limited to public sector organisations, although there are variations from country to country. In France, for instance, the law applies to both public sector organisations and large private companies and failure to comply can result in hefty fines. Whether required by a specific law or covered by a generic law, WACG guidelines<\/a> are the standard to follow for any organisation seeking to become accessibility compliant.<\/p>\n\n\n\n
While legislation is useful in forcing organisations to be accessibility compliant, what could speed things up is the threat of legal action of the ilk we are seeing in the US, as with Domino\u2019s Pizza<\/a>. In 2018, the number of federal website accessibility lawsuits nearly tripled.<\/a><\/p>\n\n\n\n
Notwithstanding, digital accessibility is not just about legislation. It\u2019s an open, buoyant and innovative market worth looking into. The European Commission estimates that<\/a> 5% of people in the EU does not use the internet because of some disability and just 10% of websites in Europe is accessible for persons with a disability. Accessibility is also important for the elderly \u2013 who account for 19.2% of the EU population \u2013 as well as people who are temporarily affected by an impairment (broken wrist, lost eyeglasses, eye disease, etc.).<\/p>\n\n\n\n
This W3C article from the Accessibility initiative<\/a> makes the business case for accessibility, exploring how accessibility can boost innovation, image and market share. Everyone can benefit from digital inclusion. <\/p>\n\n\n\n
.<\/p>\n\n\n\n
Developing an accessible webmail app<\/strong><\/h2>\n\n\n\n
Email is the no1 enterprise tool. It must therefore be accessible to all, which is why building a new webmail was such a crucial project for BlueMind. For it to be relevant and well-integrated, the issue of accessibility must be addressed from the very inception of any app and infuse every stage of development. <\/p>\n\n\n\n
Training<\/em><\/strong><\/h4>\n\n\n\n
At BlueMind, all webmail and UX developers are trained in accessibility issues and standards.<\/p>\n\n\n\n
Design<\/em><\/strong><\/h4>\n\n\n\n
Accessibility is built into the app\u2019s features from the very beginning of the design stage. Here are a few questions our team typically asks itself at the mock-up and specifications stage. <\/p>\n\n\n\n
- Can all the buttons be used from the keyboard?<\/li>
- When the app is used with a screen reader, do all the icon buttons have a text description?<\/li><\/ul>\n\n\n\n<\/figure><\/div>\n\n\n\n
- Is all the information visible for colour blind people? For example, an error message in red will be more clearly visible if it comes with an icon:<\/li><\/ul>\n\n\n\n
The webmail is also fully available in english, captions are in french for conveniency<\/figcaption><\/figure><\/div>\n\n\n\n Development<\/em><\/strong><\/h4>\n\n\n\n
In the development stage, the team uses a whole set of accessibility assessment tools (Google Lighthouse<\/a>, Axe<\/a>, WAVE<\/a>, etc.).<\/p>\n\n\n\n
Testing<\/em><\/strong><\/h4>\n\n\n\n
The trial phase is key for any software publisher. Testing accessibility is no small feat as only about 30% of accessibility issues can be detected automatically.<\/p>\n\n\n\n
<\/figure>\n\n\n\nThe app therefore has to be tested manually after implementation is complete. A great way to do this is to learn to use a screen reader such as NVDA<\/a> or ORCA<\/a>. This type of software isn\u2019t easy to get a hang of, but it is by putting yourself in a difficult situation that you are better able to understand your user. More simply, you can also test your application using a keyboard alone. The BlueMind website is fully keyboard accessible too: give it a try by leaving this article and moving to another page using your keyboard only.<\/p>\n\n\n\n
Some browser plugins can also be used to test issues to do with visual impairments. Below is a colourless version of BlueMind (for achromatopsia<\/a> sufferers) using the NoCoffee<\/a> vision simulator for Chrome.<\/p>\n\n\n\n
.<\/p>\n\n\n\n
<\/figure>\n\n\n\nHello black and white webmail!<\/p>\n\n\n\n
.<\/p>\n\n\n\n
Capitalising<\/em><\/strong><\/h4>\n\n\n\n
Capitalising on existing, consistent resources is key in ensuring first-class software development.<\/p>\n\n\n\n
Our repository of graphic components (available here: https:\/\/forge.bluemind.net\/staging\/styleguide\/abm-styleguide.html<\/a>) includes a best practices guide and a library of components that can be reused by all the actors of our solution. This also enables us to provide the best user experience possible<\/a>, both for browser and mobile usage.<\/p>\n\n\n\n
Conclusion<\/strong><\/h2>\n\n\n\n
- Is all the information visible for colour blind people? For example, an error message in red will be more clearly visible if it comes with an icon:<\/li><\/ul>\n\n\n\n
- Operable<\/strong>: User interface components and navigation must be operable.<\/li>