...
 
Commits (208)
......@@ -2,3 +2,6 @@
build
*.qmlc
*.jsc
/__pycache__
*.tags
.vscode
\ No newline at end of file
kate: space-indent on; tab-width 4; indent-width 4; replace-tabs on; eol unix;
kate-wildcard(*.rst): word-wrap-column 80; word-wrap on;
......@@ -18,3 +18,4 @@ Sphinx==1.7.0
sphinx-rtd-theme==0.2.4
sphinxcontrib-websupport==1.0.1
urllib3==1.22
sphinxcontrib-doxylink==1.6.1
......@@ -14,7 +14,7 @@
body {
font-family: "Noto Sans","Helvetica Neue", Arial, sans-serif;
font-size: 14px;
color: #232627;
color: #232629;
}
h1, h2, .rst-content .toctree-wrapper p.caption, h3, h4, h5, h6, legend {
......@@ -68,9 +68,9 @@ a.icon {
color: rgba(255,255,255,0.7);
}
.wy-side-nav-search input[type="text"] {
border-radius: 4px;
border: 0 solid transparent;
.wy-nav-content {
margin: 0 auto;
max-width: 800px;
}
.wy-nav-content-wrap {
......@@ -78,11 +78,11 @@ a.icon {
}
.wy-menu-vertical a {
color: #232627;
color: #232629;
}
.wy-menu-vertical .current a {
color: #232627;
color: #232629;
}
.wy-menu-vertical a:hover {
......@@ -96,7 +96,7 @@ a.icon {
.wy-menu-vertical li.toctree-l2.current > a {
background-color: #fcfcfc;
color: #232627;
color: #232629;
}
.wy-menu-vertical li a.current:last-of-type {
......@@ -105,7 +105,7 @@ a.icon {
}
.wy-menu-vertical li.current a {
color: #232627;
color: #232629;
border-top: none;
border-bottom: none;
}
......@@ -130,20 +130,35 @@ a.icon {
background-color: #27ae60;
}
.btn {
.btn, input.searchbtn[type="submit"] {
background-color: #eff0f1 !important;
background-image: linear-gradient(to bottom, #f2f2f3, #e8e9ea);
box-shadow: 0.5px 0.5px 0.5px 0.5px rgba(35,38,39,.1);
border-color: #bdc3c7;
border-radius: 3px;
border-width: 1px;
padding: 8px;
transition: all .1s linear;
outline: 0;
border-style: solid;
}
.btn:hover {
.btn:hover, input.searchbtn[type="submit"]:hover {
border-color: #93cee9;
background-color: #eff0f1 !important;
outline: 0;
}
.btn:active {
.btn:active, input.searchbtn[type="submit"]:active {
background-image: linear-gradient(to bottom, #9cd2eb, #76c1e3);
box-shadow: 0.5px 0.5px 0.5px 0.5px rgba(35,38,39,.1);
padding: 8px;
transform: translate(1px,1px);
outline: 0;
}
.btn:focus:not(:active), input.searchbtn[type="submit"]:focus:not(:active) {
color: #fcfcfc !important;
border-color: #3daee9;
background-image: linear-gradient(to bottom, #45b1ea, #25a4e6);
outline: 0;
}
......@@ -157,7 +172,13 @@ a.icon {
right: 0;
color: #7f8c8d;
}
.intend:before {
@media (max-width: 950px) {
.intend {
position: static;
}
}
.intend p:before {
content: "For "
}
......@@ -167,9 +188,6 @@ a.icon {
}
.available {
position: absolute;
top: 30px;
right: 0;
color: #da4453;
}
......@@ -178,11 +196,15 @@ a.icon {
}
.available.qwidgets:before {
content: 'Pattern is not available for qWidgets'
content: 'Not available for qWidgets'
}
.available.plasma:before {
content: 'Pattern is not available for Plasma'
content: 'Not available for Plasma'
}
.available.plasma.qwidgets:before {
content: 'Not available for Plasma and qWidgets'
}
@font-face {
......@@ -211,3 +233,160 @@ a.icon {
font-family:"icons";
content:"\f104";
}
.wy-nav-top {
background-color: #27ae60;
}
.wy-nav-top a:visited {
color: #fcfcfc;
}
/*
* Add more spacing and a 1px seperator between sections */
div[itemprop="articleBody"] .section:not(:first-of-type) {
margin-top: 20px;
padding-top: 20px;
}
div[itemprop="articleBody"] > .section > .section:not(:first-of-type) {
border-top: 1px solid #bdc3c7;
margin-top: 30px;
padding-top: 30px;
}
/* Increase font sized to have more visual difference */
h1 {
font-size: 300%;
margin-bottom: 8px;
font-weight: normal;
}
h2 {
font-size: 240%;
margin-bottom: 8px;
font-weight: normal;
}
h3 {
font-size: 180%;
margin-bottom: 8px;
font-weight: normal;
}
h4 {
font-size: 140%;
margin-bottom: 8px;
font-weight: normal;
}
h5 {
font-size: 120%;
margin-bottom: 10px;
font-weight: normal;
}
.rst-content img, video, audio {
height: auto !important;
max-width: 100%;
}
.do *, .dont * {
font-style: normal;
}
.do img, .dont img {
display: block;
margin: 0 auto;
}
.dont .caption {
margin-top: 7.5px;
border: 2px solid #da4453;
background-color: rgba(218, 68, 83, 0.2);
border-radius: 4px;
padding: 10px;
}
.do .caption {
margin-top: 7.5px;
border: 2px solid #27ae60;
background-color: rgba(39, 174, 96, 0.2);
border-radius: 4px;
padding: 10px;
}
.dont .iconred, .do .noblefir {
font-weight: bold;
}
.flex.docutils.container {
margin: 0 auto;
justify-content: center;
}
.wy-breadcrumbs li a:first-child {
padding-left: 5px;
}
.wy-breadcrumbs li span:first-child {
padding: 5px;
}
ul.wy-breadcrumbs > li, ul.wy-breadcrumbs a {
font-size: 15pt;
}
li.wy-breadcrumbs-aside {
margin-left: auto;
}
li.wy-breadcrumbs-aside > a {
font-size: 14px;
}
@media screen and (max-width: 768px) {
ul.wy-breadcrumbs > li, ul.wy-breadcrumbs a {
font-size: 14px;
}
}
.wy-menu-vertical a {
font-size: 10pt;
}
span.toctree-expand {
vertical-align: middle;
}
span.toctree-expand::before {
content: "" !important;
background-image: url("go-next.svg");
height: 14px;
width: 14px;
vertical-align: middle;
}
a.current span.toctree-expand::before {
filter: brightness(500);
}
.breeze-icon {
height: 16px;
width: 16px;
}
.rst-content div[role=navigation] ul {
display: flex;
align-items: center;
}
.wy-side-nav-search input[type="text"] {
min-height: 30px;
border-radius: 3px;
border: 1px solid #bcbebf;
box-shadow: none;
font-size: 10pt;
width: 90%;
}
.wy-side-nav-search input[type="text"]:focus {
border: 1px solid #3dade9;
}
input + input.searchbtn[type="submit"] {
width: 30px;
height: 30px;
background-image: url("edit-find.svg");
background-size: 16px 16px;
background-position: center;
background-repeat: no-repeat;
}
input + input.searchbtn[type="submit"]:focus:not(:active) {
background-color: #3daee9 !important;
background-image: url("edit-find-dark.svg");
}
input + input.searchbtn[type="submit"]:active {
background-color: #76c1e3 !important;
background-image: url("edit-find.svg");
}
.wy-side-nav-search input[type="text"] + input.searchbtn {
margin-left: 3px;
}
#rtd-search-form {
display: flex;
justify-content: center;
}
\ No newline at end of file
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">
<defs id="defs3051">
<style type="text/css" id="current-color-scheme">
.ColorScheme-Text {
color:#eff0f1;
}
</style>
</defs>
<path style="fill:currentColor;fill-opacity:1;stroke:none"
d="M 6.5 2 C 4.007 2 2 4.01 2 6.5 C 2 8.993 4.01 11 6.5 11 C 7.5636432 11 8.5263409 10.618801 9.2949219 10.005859 L 13.292969 14.003906 L 14 13.296875 L 10.001953 9.2988281 C 10.617604 8.529048 11 7.565338 11 6.5 C 11 4.007 8.99 2 6.5 2 z M 6.5 3 C 8.439 3 10 4.561 10 6.5 C 10 8.439 8.439 10 6.5 10 C 4.561 10 3 8.439 3 6.5 C 3 4.561 4.561 3 6.5 3 z "
class="ColorScheme-Text"
/>
</svg>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16">
<defs id="defs3051">
<style type="text/css" id="current-color-scheme">
.ColorScheme-Text {
color:#232629;
}
</style>
</defs>
<path style="fill:currentColor;fill-opacity:1;stroke:none"
d="M 6.5 2 C 4.007 2 2 4.01 2 6.5 C 2 8.993 4.01 11 6.5 11 C 7.5636432 11 8.5263409 10.618801 9.2949219 10.005859 L 13.292969 14.003906 L 14 13.296875 L 10.001953 9.2988281 C 10.617604 8.529048 11 7.565338 11 6.5 C 11 4.007 8.99 2 6.5 2 z M 6.5 3 C 8.439 3 10 4.561 10 6.5 C 10 8.439 8.439 10 6.5 10 C 4.561 10 3 8.439 3 6.5 C 3 4.561 4.561 3 6.5 3 z "
class="ColorScheme-Text"
/>
</svg>
<svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg">
<style
type="text/css"
id="current-color-scheme">
.ColorScheme-Text {
color:#232629;
}
</style>
<path d="M11.707 8l-6 6L5 13.293 10.293 8 5 2.707 5.707 2l6 6z" class="ColorScheme-Text" fill="currentColor"/>
</svg>
{%- extends "sphinx_rtd_theme/breadcrumbs.html" %}
{% block breadcrumbs %}
<li><a href="{{ pathto(master_doc) }}">Docs</a> <img class="breeze-icon" src="{{ pathto('_static/css/go-next.svg', 1)}}"> </li>
{% for doc in parents %}
<li><a href="{{ doc.link|e }}">{{ doc.title }}</a> <img class="breeze-icon" src="{{ pathto('_static/css/go-next.svg', 1)}}"> </li>
{% endfor %}
<li><span>{{ title }}</span></li>
{% endblock %}
\ No newline at end of file
{%- if builder != 'singlehtml' %}
<div role="search">
<form id="rtd-search-form" class="wy-form" action="{{ pathto('search') }}" method="get">
<input type="text" name="q" placeholder="{{ _('Search the HIG...') }}" />
<input type="submit" class="searchbtn" value="" >
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
{%- endif %}
\ No newline at end of file
Accessibility Checklist
=======================
Introduction
------------
This is a list of common things you should check for to have great
:doc:`accessibility <index>` for your application or widgets.
Keyboard Navigation
-------------------
- Efficient keyboard access is provided for all application features.
- All windows have a logical keyboard navigation order.
- The correct tab order is used for controls whose enabled state is
dependent on checkboxes, radio buttons or toggle buttons.
- Keyboard access to application-specific functions does not override
existing system accessibility features.
- The application provides more than one method to perform keyboard tasks
whenever possible.
- There are alternative keyboard shortcuts wherever possible.
- Frequently-accessed keyboard shortcuts should be physically easy to access
and not require awkwardly bending the wrist or fingers.
- The application does not require repetitive, simultaneous keypresses.
- The application provides keyboard equivalents for all mouse functions.
- The application provides keyboard equivalents for all mouse-based functions,
including selecting, moving, and resizing items.
- The application does not use any general navigation functions to
trigger operations.
- All keyboard-invoked menus, windows, and tooltips appear near the object
they relate to.
Testing
^^^^^^^
The following keyboard operations should be tested. Don't use the mouse in any
part of this test.
- Using only keyboard commands, move the focus through all menu bars in the
application.
- Confirm that:
- Context-sensitive menus display correctly.
- Any functions listed on the toolbar can be triggered using the keyboard.
- Every control in the client area of the application can be focused and
activated.
- Text and objects within the client area can be selected.
- Any keyboard enhancements or shortcuts are working as designed.
Mouse Interaction
-----------------
- No operations depend on input from the right or middle mouse buttons.
- All mouse operations can be cancelled before they are complete.
- Visual feedback is provided throughout drag and drop operations
- The mouse pointer is never moved by the application, or its
movement restricted to part of the screen by the application.
Graphical Elements
------------------
- There are no hard-coded graphical attributes such as line, border or
shadow thickness.
- All multi-color graphical elements can be shown in monochrome only,
where possible.
- All interactive GUI elements are easily distinguishable from static GUI
elements.
- An option to hide non-essential graphics is provided.
See :doc:`units </layout/units>` for more information on how to use KDE's base
units to avoid hardcoded size values.
Testing
^^^^^^^
Test the application using a screen reader and confirm that:
- Labels and text are being read correctly, including menus and toolbars.
- Object information is read correctly.
Fonts and Text
--------------
- No font styles or sizes are hard-coded.
- An option to turn off graphical backdrops behind text is provided.
- All labels have names that make sense when taken out of context.
- No label names are used more than once in the same window.
- Label positioning is consistent throughout the application.
- All static text labels that identify other controls end in a colon (:).
- Static text labels that identify other controls immediately precede
those controls in the tab order.
- An alternative to WYSIWYG is provided. For example, the ability to
specify different screen and printer fonts in a text editor.
See :doc:`typography </style/typography>` for more information on how to
avoid hardcoded font sizes and :doc:`labels </style/writing/labels>` for more
details about labels.
Testing
^^^^^^^
- Change the font in the application and confirm that the settings are
maintained.
- Test the application by changing colors and confirm that all settings are
maintained.
- If magnification is available, test the font, color, and size using the
magnification option.
Color and Contrast
------------------
- Application colors are not hard-coded, but either use colors from
current desktop theme or an application setting.
- Color is only used as an enhancement, and not as the only means to
convey information or actions.
- The application supports all available
:doc:`high contrast themes </style/color/high>` and settings.
- The software is not dependent on any particular
:doc:`high contrast themes </style/color/high>` or settings.
See :doc:`the HIG's page about color </style/color/index>` and
:doc:`colors in Kirigami <kirigami:style/color>` for more information.
Testing
^^^^^^^
- Print screenshots to a black and white printer and confirm that all
information is visible.
- Test applications using only black and white high-contrast settings and
confirm that all information is conveyed correctly.
- Test that the application provides at least three combinations of color
schemes and that high-contrast schemes are available (e.g. white on black or
yellow on blue).
- Turn on high-contrast settings in the System Settings and confirm that
the application respects these settings.
- Test various themes to ensure that the software is working for all the
available settings.
Magnification
-------------
- The application provides the ability to scale or magnify the work area.
- The application's functionality is not affected by changing the
magnification or scale settings.
Audio
-----
- Sound is not used as the only means of conveying any items of
information.
- The user can configure the frequency and volume of all sounds and
warning beeps.
Testing
^^^^^^^
There should be an option in the application to show audio alerts visually.
Test that the audio is working correctly by enabling sound in the System
Settings and then perform the following actions:
- Perform an action that should generate an audio alert and confirm that the
application is working as designed.
- Verify that the application works correctly when increasing or decreasing
the volume.
- Confirm that warning messages and alerts can be heard correctly in a noisy
work environment.
Animation
---------
- There are no flashing or blinking elements with a frequency greater than
2Hz or lower than 55Hz.
- Any flashing or blinking is confined to small areas of the screen.
- If animation is used, an option is available to turn it off before it is
first shown.
Testing
^^^^^^^
Verify that an option is available to stop animation and that it is working as
designed.
Turn the animation off. Confirm that all information is still conveyed
correctly.
Keyboard Focus
--------------
- When a window is opened, focus starts at the most commonly-used control.
- Current input focus position is clearly displayed at all times.
- Input focus is shown in exactly one window or view at all times.
- Appropriate audio or visual feedback is provided when the user attempts
to navigate past either end of a group of related objects.
- The default audio or visual warning signal is played when the user
presses an inappropriate key.
- There is sufficient audio information for the visual focus that the user
can figure out what to do next.
- Set the focus to the actual control. Don't just highlight an area.
- When using assistive technologies, such as a screen reader or braille
device, the current program indicates the position and content of the visual
focus indicator.
Testing
^^^^^^^
- Verify when moving among objects that the visual focus indicator is
easy to identify.
- Keyboard navigation through the software and menus should be clearly visible
when the focus moves.
- Confirm that the screen reader is tracking the visual focus indicator as you
navigate using a keyboard.
- Run a screen magnification program (if available) and verify that the
magnifier can track the visual focus indicator as you navigate using the
keyboard and mouse.
Timing
------
- There are no hard-coded time-outs or time-based features in the
application.
- The display or hiding of important information is not triggered solely
by movement of the mouse pointer.
Testing
^^^^^^^
- Test all messages to confirm that the user is notified before a message
times out and is given the option to indicate that more time is needed.
- Make sure an option has been included to adjust the response time and
confirm that it is working as designed.
Documentation
-------------
- All documentation is in an accessible format, with textual alternate
descriptions provided for all figures and diagrams.
- The documentation includes a section that covers all the application's
accessibility features.
Testing
^^^^^^^
Test ASCII text documentation with a screen reader to confirm that it is clear
and precise and can be read by assistive technologies.
Test HTML applications using a web browser and screen reader to confirm that the
documentation is accessible to assistive technologies.
Note: There are web accessibility guidelines available at
`<http://www.w3.org/TR/WAI-WEBCONTENT/>`_.
Confirm the following information is included in the documentation:
- State if the application does not support the standard keyboard access used
by the OS.
- Identify if there are unique keyboard commands.
- Identify any unique accessibility features.
- If an action is documented for the mouse, make sure there is an alternative
for using the keyboard.
.. note::
The content of this page is based on
`<https://developer.gnome.org/accessibility-devel-guide/3.32/\
accessibility-devel-guide.html>`_
Accessibility
=============
.. toctree::
:maxdepth: 1
:titlesonly:
:hidden:
checklist
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*: `<https://en.wikipedia.org/wiki/Accessibility>`_
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 does not always
mean that they are blind. For some people it's enough when
:doc:`fonts </style/typography>` are clear and the
:doc:`color scheme </style/color/index>` 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 </style/color/dark>` and see that
your application is still usable
- Test changing the :doc:`font size </style/typography>`
- 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. Therefore 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 only makes sense when seeing the
arrangement of buttons, or only has an image as label, then you need to help the AT
read the button. If you don't, it will only say the type of the widget, "Button"
which is not 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, you just need to find where it's initialized.
Once you find it (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 <https://doc.qt.io/qt-5/accessible.html>`_ on how to create
accessible QML applications. The concepts are generally the same as for QWidget
based applications.
......@@ -4,7 +4,7 @@ Emblem
Purpose
-------
An *emblem* displays unusual or non-default status information about an icon
An emblem displays unusual or non-default status information about an icon
or image. For example, an emblem could indicate that a folder is shared, that a
disk is unmounted, or that an app has unread notifications.
......@@ -28,7 +28,7 @@ Guidelines
in a file manager, system tray, task manager, dock, image view, etc. Emblems
should not be applied to textual content.
- Use emblems to display that an icon or image has some unusual status
associated with it, or that there are unread notifications. Do not use
associated with it, or that there are unread notifications. Don't use
emblems to display an element's normal, common, or typical status. For
example, an emblem could indicate that a folder is read-only or is a symlink,
or that a disk is unmounted or encrypted. An emblem should not be used to
......@@ -38,20 +38,11 @@ Guidelines
in a clockwise order.
- Emblems that indicate unread notifications should be located in the
top-right corner.
- Use the minimum number of emblems and do not overwhelm the icon itself.
- Use the minimum number of emblems and don't overwhelm the icon itself.
Three is usually too many.
Appearance
----------
An emblem that indicates status should take the form of a light-colored symbol
on top of a brightly-colored shape.
.. figure:: /img/emblem-warning.png
:alt:
Warning emblem
An emblem that indicates unread notifications should take the form of a
light-colored number inside a blue circle. The circle can become "pill-shaped"
if the number is very large.
......@@ -65,3 +56,6 @@ if the number is very large.
:alt:
Notification emblem with a large number
For symbolic icon emblems, see the :doc:`Breeze icon guidelines </style/icon>`.
Inline message
Inline Message
==============
.. container:: intend
|desktopicon| |mobileicon|
Purpose
-------
A *inline message* is a small pop-up panel shown at top of the current
form that informs users of a non-critical problem or special condition.
The panel shows information on four levels indicated by different colors
and icons, and provides standard action that users might want to
initiate.
A inline message is a small panel that informs users of a non-critical problem
or special condition. It is embedded in the content and should not overlap
content or controls. The panel has four visual style options which can be used
for neutral messages, success conditions, warnings, and errors. It can also be
given buttons.
.. figure:: /img/Message5.qml.png
.. figure:: /img/Message5.png
:alt: Different levels of inline messages.
:scale: 80%
......@@ -30,21 +35,23 @@ Guidelines
- Use inline messages in cases of non-critical problems that user can
solve.
- Use *negative feedback* (aka error) as a secondary indicator of
failure, e.g. if a transaction was not completed successfully
- Show the information on a warning level in case of relevant
information that do not concern the current workflow, e.g. No
Internet connection available.
- Use *positive feedback* to notify about user-initiated processes,
e.g. to indicate completion of background tasks
- Use *opportunistic interaction* (aka notification) to acknowledge
- Use :iconred:`negative feedback` (aka error) as a secondary indicator of
failure, e.g. if a transaction was not completed successfully.
- Show the information on a warning level in case of relevant
information that does not concern the current workflow, e.g. No
Internet connection available.
- Use :noblefir:`positive feedback` to notify about user-initiated processes,
e.g. to indicate completion of background tasks.
- Use :plasmablue:`opportunistic interaction` (aka notification) to acknowledge
the user about options that he or she might be interested in, e.g.
"Remember password?"
- Display the information immediately.
- When users dismiss the inline message, do not display any other UI or start
- When users dismiss the inline message, don't display any other UI or start
an