====== Checklist accessible desktop and mobile app programming ======

When programming desktop and mobile apps, the recommendations of the manufacturing software company should be carefully read, observed and implemented in the design, planning, programming and testing.
The following links are the entry points to the documentation of large software companies on this topic.
Every programmer or group of programmers must deal with this topic and activate accessibility features especially for the developed application. This applies to development projects and contracts that are outsourced.

<WRAP center round important 60%>
Not considering accessibility in published apps is not an option! 

</WRAP>

===== Documentations for desktop applications =====

  * Microsoft: https://docs.microsoft.com/en-us/windows/win32/winauto/about-windows-accessibility-features
  * Apple: https://developer.apple.com/accessibility/macos/
  * Ubuntu: https://wiki.ubuntu.com/Accessibility
  * RedHat : https://access.redhat.com/help/accessibility/
  * SUSE : https://www.suse.com/de-de/products/accessibility/

<WRAP center round info 80%>
==== Related GWDG news articles ====
  - [[https://gwdg.de/about-us/gwdg-news/2023/GN_7-8-2023_www.pdf#page=15|GWDG News 7-8|23]] - Accessible Software Development with Microsoft Visual Studio 2022
  - [[https://gwdg.de/about-us/gwdg-news/2024/GN_01-02-2024_www.pdf#page=8|GWDG News 1-2|24]] - Creating accessible applications with semantic properties in .NET MAUI

<WRAP center round important 60%>
German only!
</WRAP>

</WRAP>
===== Documentations for mobile applications=====

  * Apple https://developer.apple.com/accessibility/ios/
  * Android https://developer.android.com/guide/topics/ui/accessibility

===== API naming =====
<WRAP center round info 60%>
The golden rule is: **Use word separators**

</WRAP>

====API and schema design examples====
  - use_underscores
  - useCamelCase
  - use-kebab-case

==== Examples of IDs and similar entities ====
  - use.dot.separators (often with reverse DNS prefixes)
  - use/path/separators (often with URIs)
  - use-hyphen-separators (often with GUIDs and the like)

==== Abbreviations ====
Another common challenge is the use of shortcuts. While a user interacting with your API may recognize your abbreviations from context, a screen reader may not be able to do so, especially if your abbreviation is not common.
^Abbreviated (unfavorable) ^Not abbreviated (correct) ^
| pvtKey | privateKey |

==== Additional services ====
An added benefit is that code generators can more easily produce idiomatic terms that conform to case-sensitive conventions in the target language/platform.
^JSON ^Dotnet ^Dotnet with additional suffix ^
| dataContentType | DataContentType | DataContentTypeEntity |


===== Check list =====
^ Done ^ Checkpoints ^
|           | Interfaces built-in and tested |
|           | Bilingualism implemented |
|           | Usability implemented via mouse and keyboard |
|           | API Naming |
{{:en:general:checkliste_barrierefreie_desktop-_und_mobile-app_programmierung.pdf|The checklist to download }}