diff --git a/source/accessibility/index.rst b/source/accessibility/index.rst new file mode 100644 index 0000000..dd17099 --- /dev/null +++ b/source/accessibility/index.rst @@ -0,0 +1,153 @@ +Accessibility +============= + +Introduction +------------ + + Accessibility is the design of products, devices, services, or environments + for people with disabilities. The concept of accessible design and + practice of accessible development ensures both "direct access" (i.e. + unassisted) and "indirect access" meaning compatibility with a person's + assistive technology. + + *Source*: ``_ + +But good accessibility benefits all users. A working keyboard navigation and +well choosen colors and fonts setting not only help people with low vision, +blindness, deafness, cognitive or motor impairments or +situational disabilities, like a broken hand, but also improve the workflow and +usability for all users. + +Fonts and Colors +---------------- + +Many users have some deficiencies when it comes to seeing. This doesn't always +mean that they are blind. For some people it is enough when +:doc:`fonts ` are clear and the +:doc:`color scheme ` can be adjusted. This is something +every application should do in any case, so here is the list: + +- Follow the user interface guidelines! This will get you quite far. +- Check that color scheme changes apply |br| + Try switching to a :doc:`dark color scheme ` and see that + your application is still usable + +- Test changing the :doc:`font size ` + + - Switch to different fonts and see that they apply + - Increase the font size and make sure that the application layout still + works + + +Keyboard +-------- + +When you have problems seeing, the mouse is quite hard to use. The keyboard is a +lot more reliable. Therefor it is important that applications can be used with +the keyboard. For some users, using a mouse is difficult because of motor skill +issues. Making applications keyboard accessible benefits everyone, since it +allows us to use shortcuts to use the applications more efficiently. + +- Try to operate your application with the TAB key + + - Make sure that the tab order is correct + - Start your application and do a common task without using the mouse + + Note where you had trouble and think about possible improvements in the + UI or keyboard shortcuts that are missing + +Screen Reader +------------- + +There is a lot you can help with to make applications accessible to screen +reader users. We refer to screen readers and other assistive technology often as +AT. + +.. TODO:: + + Setup Screen Readers with KDE + Gives detailed setup instructions for screen readers. + + +Testing +------- + +This section gives a quick intro what to look for when testing an application +with a screen reader. + + +Once you have an application running with the screen reader: Make sure Orca says +something intelligible for all elements. When it reads a GUI element it should +say the label and type, eg: "File, Menu" or "OK, Button". When you have a button +that does not have a label, maybe because it shows a picture only, add +accessibility hints. Try navigating the more troublesome elements - comboboxes +and lists and such. + + +Fixing missing information +-------------------------- + +For many things there are usually easy fixes involving no advanced programming +skills but just fixing some details. + +For this tutorial we assume that you are dealing with a QWidget that is seen by +the AT but does for example give not enough information. + +There are two important properties that every QWidget has: an "Accessible Name" +and an "Accessible Description". The name is short, for example the label on a +button. It should always be short. The description on the other hand is the more +verbose "this button does foo and then bar". Qt will try hard to return +something for the name. In case of a button, usually the text on the button is +returned. But if your button has text that makes only sense when seeing the +arrangement of buttons, or only has an image as label, you need to help the AT +read the button. If you don't, it will only say the type of the widget, "Button" +is not a very helpful information. + + +Fixing Accessible Name and Description +-------------------------------------- + +Fire up Qt designer if the app uses .ui files. You'll find the properties and +can type the name/description right in. After saving the file, rebuild and +install the application. You are done, submit a patch to fix the ui file. + +If the widget is created in the code, just need to find where. Once you found +the widget, usually where it's created, add some code to it: + +.. code-block:: c++ + + button->setAccessibleName(i18n("Open")); + button->setAccessibleDescription(i18n("Opens a file dialog to select a new + foo")); + +Send your patch. + +Sometimes you also want to override the label for a different reason. One of my +test apps was the calculator example from Qt. It has a memory recall button +labelled "MR". Orca will insist on this being the "Mister" button, unless told +otherwise. + + +Complex Widgets +--------------- + +For some widgets the above is not enough. You will have to create +QAccessibleInterfaces for widgets that you create yourself. For example Kate has +an interface for its text editing area. Sometimes you need to inherit +QAccessibleTextInterface or QAccessibleValueInterface in order to make the +widgets properly accessible. Refer to the Qt documentation how to do this. + + +QGraphicsView +------------- + +Currently there is no support for accessibility in QGraphicsView. + + +Qt Quick (QML) +-------------- + +For Qt 5, refer to the +`documentation `_ on how to create +accessible QML applications. The concepts are generally the same as for QWidget +based applications. diff --git a/source/index.rst b/source/index.rst index df5e0a6..fb897d0 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,88 +1,89 @@ .. KDE HIG documentation master file, created by sphinx-quickstart on Tue Feb 6 13:29:47 2018. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. KDE Human Interface Guidelines ============================== .. toctree:: :titlesonly: :hidden: introduction/index layout/index style/index components/index patterns/command/index patterns/content/index patterns/navigation/index + accessibility/index plattform/index resources/about resources/contribute resources/glossary .. Indices and tables ================== * :ref:`genindex` * :ref:`modindex` * :ref:`search` The KDE Human Interface Guidelines (HIG) offer designers and developers a set of recommendations for producing beautiful, usable, and consistent user interfaces for convergent desktop and mobile applications and workspace widgets. Their aim is to improve the experience for users by making application and widget interfaces more consistent and hence more intuitive and learnable. .. figure:: /img/HIGDesignVisionFullBleed.png :scale: 50 % :alt: Different DPIs on desktop and mobile ''Simple by default, powerful when needed.'' Design Vision ------------- KDE's design vision focuses on two attributes of KDE software that connect its future to its history: - **Simple by default** - Simple and inviting. KDE software is pleasant to experience and easy to use. - **Powerful when needed** - Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive. Design Principles ----------------- The following design principles are used in support of the Design Vision. - **Simple by default** - *Make it easy to focus on what matters.* - Remove or minimize elements not crucial to the primary or main task. Use spacing to keep things organized. Use color to draw attention. Reveal additional information or optional functions only when needed. - *I know how to do that!* - Make things easier to learn by reusing design patterns from other applications. Other applications that use good design are a precedent to follow. - *Do the heavy lifting for me.* - Make complex tasks simple. Make novices feel like experts. Create ways in which your users can naturally feel empowered by your software. - **Powerful when needed** - *Solve a problem.* - Identify and make very clear to the user what need is addressed and how. - *Always in control.* - It should always be clear what can be done, what is currently happening, and what has just happened. The user should never feel at the mercy of the tool. Give the user the final say. - *Be flexible.* - Provide sensible defaults but consider optional functionality and customization options that do not interfere with the primary task. .. note:: Note: KDE encourages developing and designing for customization, while providing good default settings. Integrating into other desktop environments is also a virtue, but ultimately we aim for perfection within our own Plasma desktop environment with the default themes and settings. This aim should not be compromised. diff --git a/source/resources/glossary.rst b/source/resources/glossary.rst index ec552c8..3294030 100644 --- a/source/resources/glossary.rst +++ b/source/resources/glossary.rst @@ -1,39 +1,43 @@ Glossary ======== - **Human Interface Guidelines**, **HIG** A set of recommendations for designing and developing user interfaces for mobile, desktop, convergent applications and workspace widgets. - **User Interface**, **UI** In the field of human–computer interaction, the User Interface is the space where interactions between humans and machines occur. The goal of this interaction is to allow effective operation and control of the machine from the human end, whilst the machine simultaneously feeds back information that aids the operators' decision-making process. *Source*: ``_ - **User Experience**, **UX** UX refers to a person's emotions and attitudes about using a particular product, system or service. It includes the practical, experiential, affective, meaningful and valuable aspects of human–computer interaction and product ownership. Additionally, it includes a person’s perceptions of system aspects such as utility, ease of use and efficiency. User experience may be considered subjective in nature to the degree that it is about individual perception and thought with respect to the system. User experience is dynamic as it is constantly modified over time due to changing usage circumstances and changes to individual systems as well as the wider usage context in which they can be found. In the end, user experience is about how the user interacts with and experiences the product. *Source:*: ``_ -- **Get New Stuff **, **GNS** +- **Get New Stuff**, **GNS** :doc:`/plattform/getnew` + +- **Aassistive technology**, **AT** + + Screen readers and other assistive technology is often refered as AT