Accessibility in DestinE Climate Game ===================================== Presentation ------------ This documentation provides a summary of current accessibility standards, guidelines regarding design choices upon developing and publishing a game on the web and technical solutions we developed using Godot. Examples and solutions shown were designed specifically for the web application "DestinE Climate Game" in the context of the ESA DestinE demonstrators. Introduction ------------ With the rapid development of software technology and the adoption of the web by nearly 2/3 of the population, finding practical accessibility solutions for developers was a necessity and led to the development of standards. We took Web Content Accessibility Guidelines (WCAG) as a reference to build a sense of continuity between surfing the web and using our web application. Since our web application is also a game we took great advice from the Game Accessibility Guidelines (GAG) to optimize the user experience. Groups of disabilities ---------------------- The WCAG defines different groups of disabilities: * **Visual**\ : Impairments such as blindness, low vision, poor eyesight, and various forms of color blindness. * **Motor/Mobility**\ : Challenges or inability to use the hands, including tremors, muscle slowness, or loss of fine motor control, often caused by conditions like Parkinson’s disease, muscular dystrophy, cerebral palsy, or stroke. * **Auditory**\ : Deafness or hearing impairments, including individuals who are hard of hearing. * **Speech**\ : Speech disabilities include difficulty producing speech that is recognizable by others or by speech recognition software. For example, the loudness or clarity of someone’s voice might be difficult to understand. * **Cognitive and Intellectual**\ : Developmental disabilities, learning difficulties (e.g., dyslexia, dyscalculia), or cognitive impairments (e.g., PTSD, Alzheimer’s) that may impact memory, attention, developmental maturity, problem-solving, or logical reasoning. For the sake of development time optimization, some design choices can be made at the start or cut altogether without impacting the experience so understanding the lengths of this topic is key. For instance in our case we identified elements that could trigger photosensitive epileptic seizures and avoided them: screen flashs and rapid color changes that are very common in video games were discarded from the start. Another example would be the implementation of high-contrast icons by default instead of developing an option for it. More on design choices later. Web Content Accessibility Guidelines (WCAG) ------------------------------------------- Since 2012, WCAG 2.0 is an ISO international standard for web accessibility. WCAG 3.0 is under development as Internet is in constant evolution. WCAG 2.0 is a series of 12 guidelines divided in 4 principles: * **Perceivable**\ : Text alternative, Time-based media, Adaptable, Distiguishable > Available through sight, hearing or touch. * **Operable**\ : Keyboard accessible, Enough Time, Seizures, Navigable, Input Modalities > Compatible with keyboard, mouse, voice control and other devices. * **Understandable**\ : Readable, Predictable, Input Assistance > Easy to understand. * **Robust**\ : Compatible > Works accross browsers, assistive technologies, mobile devices & follows standards. Here is an image that summarizes all the WCAG 2.0 standards: .. image:: img/wcag-standards-at-a-glance.jpg :target: img/wcag-standards-at-a-glance.jpg :alt: WCAG standards Image source: `https://sonix.ai/resources/fr/conformite-wcag/ <>`_ Each guideline contains a set of success criteria (total 61) that must be met at different levels of conformance for different group of people: A, AA or AAA. The definition of each level is too complex to go into details here but understand that AAA will comply with more people than AA and AA than A. For each success criterion, a set of techniques is given to help developers to test if their website is compliant or not to the WCAG in very specific domains and examples. Europe and Web Accessibility ---------------------------- In 2016, Europe parliament published the Directive 2016/2102 which imposed all governmental websites to comply with the WCAG 2.1 level AA which means that every guideline must comply with level A and level AA. Europe is currently working on the European Accessibility Act (EEA), that will be implemented in June 2025, to enlarge the WCAG 2.1 level AA rule to all European websites, apps, eBooks, ecommerce platforms and PDFs. Game Accessibility Guidelines ----------------------------- WCAG 2.0 guidelines can be enlightening for game development but don't apply systematically because the environment is different and some adaptations are to be made. The Game Accessibility Guidelines was created in 2012 by a group of game studios and academics, its purpose is to provide developers with a practical guide to making games more accessible. As with WCAG, GAG splits its guidelines into 3 categories: basic, intermediate and advanced. But instead of groups of people each category represents a balance of Reach (number of people who benefit), Impact (the difference made to those people) and Value (cost to implement). Accessibility design choices for DestinE Climate Game ----------------------------------------------------- To design good user-machine interfaces is to design a frictionless interface. Thinking about how the target audience will interact with the game, for how long and for what goals are good questions to trim further accessibility questions. Friction (or challenge) is often what is looked after in a game, but not in the case of an educational game like DestinE Climate Game. To reduce friction the game is played the same way as browsing a web site: everything can be done with the mouse or keyboard, there are buttons, windows, popups and so on. It also has the color palette of Destination Earth so the player might feel a familiar setting. But unlike a website, the final goal to educate about climate change is made through a linear, narrative-driven experience. From the very start, players are greeted by Desty, a robot companion who is both educational and engaging. Desty guides users through every stage of the gameplay, explains the game’s context in a clear and reassuring manner. The player does not need to learn new controls and Desty's constant presence reduces players' cognitive load with predictable and tailored instructions for each situation. Thus by design we reduced friction and at the same time answer most needs on the *cognitive and intellectual* aspect of accessibility. The interface has then been designed to accommodate specific needs of players. **\ *To support players with visual impairments:*\ ** * **Colorblind Filters**\ : Allow players to adjust colors and improve readability. * **High Contrast Mode**\ : Enhances the distinction between visual elements. * **Adjustable Text and Icon Sizes**\ : Players can customize the typography to suit their needs. * **Alternative Cursor**\ : Improves visibility against various backgrounds. **\ *To support players with motor limitations:*\ ** * **Keyboard Navigation**\ : The entire game can be accessed without a mouse. * **Sufficient Interaction Time**\ : Players are given the flexibility to complete tasks at their own pace. **\ *To simplify the experience for players with learning or cognitive challenges:*\ ** * **Logical Structure**\ : A clear and predictable interface reduces cognitive effort. * **Explicit Icons**\ : Accompany textual information to improve understanding. * **Guidance and Contextual Assistance**\ : Desty intervenes to clarify game mechanics. **\ *The game has been designed to minimize risks associated with photosensitive epilepsy:*\ ** * No rapid or strobe-like light effects are used. * An option to adjust screen brightness is provided to reduce visual strain. GODOT Technical implementation ------------------------------ Colorblind filters ^^^^^^^^^^^^^^^^^^ We use a process called Daltonization performed by the computer that allows people with color vision deficiencies to distinguish a range of detail they are otherwise excluded from perceiving. In the game each pixel is processed to help with Protanopia, Deuteranopia and Tritanopia symptoms through a canvas_item shader. This shader is activated and altered by the UIManager given user inputs. High Contrast Mode ^^^^^^^^^^^^^^^^^^ This mode alters colors of all interactive elements and all readable elements of the game. It effectively changes dialog backgrounds, quizz backgrounds, graphs, clickable icons and buttons. Because of the variety of elements and the various situations in which the player can be when triggering the option the implementation of that feature is made through a Signal being emitted from the UIManager. This allows for each element to react to the change and perform specific operations. For most elements it would be changing the color of a background either via changing its style (StyleBox files) or by changing its modulating color. Adjustable Text and Icon Sizes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This option can be tricky to implement depending on the project if not thought well in advance. This option whanged all text sizes as well as buttons and interactive icons. The way we approached it was to first make sure that the default size, alignment of elements and margins were well spaced enough so that it might be modified without breaking layouts. In GODOT this means using the "Anchor" layout option everywhere so that when an element is scaled it changes its size without loosing its pivot point thanks to it being anchored. When the option is checked, all text-sizes and image-based elements are increased by a third. Text is changed within the UIManager by modifying sizes in the main Theme file. Image-based elements are modified through a small function triggered by a Signal emitted from the UIManager (generally via the auto_resize_texture script): the function changes the custom_minimum_size values of its element which is compatible with layout anchors (which is not the case if you modify the size or scale of the element). Alternative Cursor ^^^^^^^^^^^^^^^^^^ Changes the cursor to be bigger and have an alternative high-contrasted look. Triggered in UIManager, calls Input.set_custom_mouse_cursor to change the texture of the cursor as well as its hotspot (the exact pixel used for interactions) point. Keyboard navigation ^^^^^^^^^^^^^^^^^^^ Keyboard navigation is enabled by default and can't be turned off. Elements are organized by groups sharing a common purpose (buttons displayed in a popup, buttons located in a specific area etc). Tabulation is used to browse grouped items. Arrows are used to jump from group to group. GODOT identifies selected element with a "Focus" state which should have a visual feedback so that the player knows what he currently has as focused/selected. GODOT does not offer a simple way to handle keyboard navigation. It supports shortcuts and basic navigation between elements but as soon as more than one layer is displayed (such as when a popup appears for instance), what is being selected and what comes next will not be intuitive and in many cases the navigation is blocked. We internally developed a method available from the UIManager called FocusLayoutSetup which identifies elements and group them together to follow the rule given above. Sometimes when the player advances through the game, the focused item must be changed and often it also means that we must recalculate all selectable elements through another call to FocusLayoutSetup. We also allow the user to access an overlay menu (to quit or change accessibility settings at any moment) through the "Escape" key and let they return where they were by pressing "Escape" again. Some specific code is also written to allow navigation through maps such as when the player must localize or find a place on an openstreet map. Sufficient Interaction Time ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The game autosaves the player's progression which can then be charged at a later date at the beginning of the game. The player is never forced to read a text or act within an arbitrary timing. This way the player can always pause or take their time. The autosave feature was made using GODOT read&write capacities for "Resource" files. A "autosave" file containing player decisions and game data is stored inside their browser and is checked at the start of the game. When loaded the player is warped directly to where they were without additional charging times to ensure a smooth experience. Sources ------- * Web accessibility: `https://fr.wikipedia.org/wiki/Accessibilit%C3%A9_du_web `_ * WCAG: `https://www.w3.org/WAI/fundamentals/accessibility-intro/ `_ `https://www.w3.org/WAI/WCAG22/quickref/ `_ `https://www.w3.org/WAI/standards-guidelines/wcag/ `_ `https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines `_ * Game Accessibility: `https://gameaccessibilityguidelines.com/ `_ `https://en.wikipedia.org/wiki/Game_accessibility `_ * Europe Accessibility Directive: `https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016L2102 `_