diff --git a/HIG/source/accessibility/checklist.rst b/HIG/source/accessibility/checklist.rst new file mode 100644 index 0000000..af86dc6 --- /dev/null +++ b/HIG/source/accessibility/checklist.rst @@ -0,0 +1,272 @@ +Accessibility checklist +======================= + +Introduction +------------ + +This is a list of common things you should check for to have great +:doc:`accessibility ` 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. Do not 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 ` 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 ` for more information on how to +avoid hardcoded font sizes and :doc:`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 ` and settings. +- The software is not dependent on any particular + :doc:`high contrast themes ` or settings. + +See :doc:`the HIG's page about color ` and +:doc:`colors in Kirigami ` 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 +``_. + +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 + ``_ diff --git a/HIG/source/accessibility/index.rst b/HIG/source/accessibility/index.rst index dd17099..951f227 100644 --- a/HIG/source/accessibility/index.rst +++ b/HIG/source/accessibility/index.rst @@ -1,153 +1,160 @@ 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*: ``_ 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/HIG/source/introduction/research.rst b/HIG/source/introduction/research.rst index d791c65..cae7968 100644 --- a/HIG/source/introduction/research.rst +++ b/HIG/source/introduction/research.rst @@ -1,95 +1,95 @@ Project User Research Profile ============================= Short summary description of the purpose of the application, who it is for, and what those people can do with it. Purpose ======= **About the Project User Research Template:** The purpose of this template is to provide a place to document an application's user research information for reference during development. Top level items are information everyone in the project should be aware of. Some of the details in the lower sections may take some work and discussion within the project to complete. Who is the application for? --------------------------- - List of types (groups) of users - User groups can be organized based on any type of dimension - Some groups may be broken down in to sub groups (Who is the application *not* for) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Sometimes it is easy to identify who the application is **not** for - This can help keep the scope of the project under control Sample User Profiles ~~~~~~~~~~~~~~~~~~~~ User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know. What kinds of tasks will they complete -------------------------------------- - List of common tasks users will complete - This does not have to be a complete functional specification, but major tasks and specialty tasks should be listed - Include functionality that is planned but not yet implemented to help keep the future in focus (What kinds of functionality will the application *not* support) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - List tasks or functionality the application will not address - Sometimes it is useful to list this unintended functionality to help keep the scope of the application - For example, a certain functionality may not be implemented because it is out of scope with the primary goals of the project, another application with a different focus does it better, or it is an extreme edge case for a user type which is not primary Sample Use Scenarios and Cases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use Scenario 1: For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task *independent* of how they would complete it within the application. Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application. There may be branching or multiple ways to complete the task, and this is a good way to document it. Environment Conditions & Requirements ------------------------------------- - List of environmental conditions for the user or the application to consider - For example, an Internet-capable application would require an Internet connection More Information ---------------- `Short introduction to user personas on Usability.gov`_ `In-depth discussion about creating personas on Boxes and Arrows`_ .. _Short introduction to user personas on Usability.gov: http://www.usability.gov/analyze/personas.html .. _In-depth discussion about creating personas on Boxes and Arrows: http://www.boxesandarrows.com/view/making_personas_more_powerful_details_to_drive_strategic_and_tactical_design Still Need Help? ---------------- -CFor more information and help you can find us on +For more information and help you can find us on `Matrix `_, `IRC `_ or -`Telegram `_ \ No newline at end of file +`Telegram `_ diff --git a/HIG/source/style/icon.rst b/HIG/source/style/icon.rst index 93871d5..adcb40a 100644 --- a/HIG/source/style/icon.rst +++ b/HIG/source/style/icon.rst @@ -1,396 +1,402 @@ Icon Design =========== Purpose ------- Icons are pictorial representations of functions and objects. They convey meaning that users perceive almost instantaneously and are an important part of a program's visual identity. Well-designed icons strongly impact users' overall impression of the design. Consistent use of icons also improves usability by making programs, objects, and actions easier to identify and learn. -If you would like to request help designing icons for your application, you can -ask the `KDE Visual Design Group `_ for help. +.. note:: + + See the `workflow tips on how to create an icon \ + `_ if + you are interested in designing icons for your application. Or you can + ask the `KDE Visual Design Group \ + `_ + for help. General Guidelines ------------------ - Use icons from the system icon theme whenever possible. Avoid using custom icons. New icons should be added to an icon theme. - Design icons with a small number of metaphors that are understandable independent of language and culture. Apply metaphors only once (e.g. do not use a brush twice for different actions). - Simplify, but don't go overboard. Breeze icons are **not** "flat". - Avoid using text in icon designs; it cannot be localized and tends to look bad at small sizes. - Many icons come in multiple sizes. Each version should be visually optimized and pixel-perfect for its particular size. Larger sizes offer more opportunity for detail and visual pizazz, while smaller version should be stripped of everything not absolutely necessary. Monochrome icon style --------------------- .. image:: /img/HIGMonoIcons.png :alt: Monochrome icons Many Breeze icons employ a monochrome art style for their small 16px and 22px versions. This style should be avoided for icons larger than 22px. The monochrome style relies on distinct shapes and outlines instead of fine details and vibrant colors, and employs an intentionally limited color palette: #. |shadeblack| :doc:`Shade Black `: Used for icons in a normal state and non-destructive actions: back, forward, ok, home, etc. This is the most commonly used color. When in doubt, choose Shade Black. #. |iconred| :doc:`Icon Red`: Used for icons that depict actions: delete, remove, stop, etc. #. |bewareorange| :doc:`Beware Orange `: Used for icons that involve user input of some kind. #. |plasmablue| :doc:`Plasma Blue `: Used for icons that involve the action "select" or "insert". #. |iconyellow| :doc:`Icon Yellow `: Used for icons that involve a "warning" state or some sort. #. |noblefir| :doc:`Noble Fir `: Used to for icons that involve "connected", "secure" or "successful" actions. .. |shadeblack| image:: /img/Breeze-shade-black.svg .. |iconred| image:: /img/Breeze-icon-red.svg .. |bewareorange| image:: /img/Breeze-beware-orange.svg .. |plasmablue| image:: /img/Breeze-plasma-blue.svg .. |iconyellow| image:: /img/Breeze-icon-yellow.svg .. |noblefir| image:: /img/Breeze-noble-fir.svg Because monochrome icons are so small and simple, it is important that they be pixel-perfect, with their lines and objects aligned to a regular grid: .. image:: /img/Breeze-icon-design-3.png :alt: Newspaper icon .. image:: /img/Breeze-icon-design-1.png :alt: A pixel-perfect icon on the canvas. .. image:: /img/Breeze-icon-design-2.png :alt: A pixel-perfect icon in the app. *Pixel-perfect icons: On the canvas and in the app* Because monochrome icons usually depict actions, many include status or action emblems. These are always located in the bottom-right corner. The emblem should be a minimum of 5px wide and tall, and there must be 1px of blank space between the emblem and the rest of the icon. .. image:: /img/Breeze-icon-design-8.png :alt: Design for a 22px or 16px icon with an emblem in the bottom-right corner *A perfect monochrome icon with an emblem in the corner* Margins ~~~~~~~ .. image:: /img/icon_margins-monochrome-4x.png :alt: Canvas and graphic sizes :download:`Larger size ` Colorful icon style ------------------- .. image:: /img/Sample_color_icons.png :alt: Colorful icons Colorful Breeze icons make full use the :doc:`Breeze color palette `. They are **not** "flat" and incorporate shadows and smooth linear gradients going from darker on the bottom to lighter on top. Don't be afraid to add detail, vibrancy, and depth! Colorful Breeze icons generally consist of three parts: Background ~~~~~~~~~~ The background is a container and gives structure to the icon. It can have any shape or color in the Breeze color palette. Don't be afraid to get creative with the background shape! .. image:: /img/Breeze-icon-design-creative-backgrounds.png :alt: Creative backgrounds Foreground symbol ~~~~~~~~~~~~~~~~~ The foreground symbol offers contrast with its background and works with it to provide the bulk of the icon's meaning. The foreground symbol is optional; feel free to omit it if the background provides enough meaning on its own. Shadows ~~~~~~~ If present, the foreground symbol casts a long shadow angled 45° towards the bottom-right corner. This shadow always has the same gradient and takes up the whole object. .. image:: /img/Breeze-icon-design-10.png :alt: Using the grid for shadows In addition, colorful icons have a 1 px hard shadow on the bottom: .. image:: /img/Breeze-icon-design-12.png :alt: 48px icons can have more details Margins ~~~~~~~ .. image:: /img/icon_margins-color-4x.png :alt: Canvas and graphic sizes :download:`Larger size ` Application icons ----------------- Application icons come in a single size: 48px. They always use the colorful style. All application icons should have the same height: 40px tall, with four pixels of padding on the top and bottom. When creating a Breeze theme version of an existing app's icon, is critically important that the icon's existing brand and visual style be preserved. The goal is to create a Breeze version of the icon, not something completely new and different. .. image:: /img/Breeze-icon-design-15.png :alt: KDE app icon for Konsole *KDE app icon for Konsole* .. image:: /img/Breeze-icon-design-Kolourpaint.png :alt: KDE app icon for Kolourpaint *KDE app icon for Kolourpaint* .. image:: /img/Breeze-icon-design-11.png :alt: KDE app icon for Discover *KDE app icon for Discover* .. image:: /img/Breeze-icon-design-14.png :alt: 3rd party app icon for VLC *3rd party app icon for VLC* .. image:: /img/Breeze-icon-design-Telegram.png :alt: 3rd party app icon for Telegram *3rd party app icon for Telegram* .. image:: /img/Breeze-icon-design-Virtualbox.png :alt: 3rd party app icon for Virtualbox *3rd party app icon for Virtualbox* Places icons ------------ Places icons come in four sizes: 16px, 22px, 32px, and 64px. They use the colorful style for 32px and 64px sizes and the monochrome style for 22px and 16px sizes. Monochrome Places icons ~~~~~~~~~~~~~~~~~~~~~~~ Places icons are monochrome for their 16px and 22px versions. For these versions, the whole icon depicts the place itself or its typical contents. Beyond that, simply follow the general monochrome icon guidelines for 16px and 22px icons. .. image:: /img/Breeze-icon-design-places-monochrome.png :alt: Small monochrome Places icons *Small monochrome Places icons in Dolphin's Places panel* Colorful places icons ~~~~~~~~~~~~~~~~~~~~~ .. image:: /img/Breeze-icon-design-places.png :alt: Colorful Places icons For the colorful versions, the monochrome icon becomes the foreground symbol on top of a background depicting a folder. The foreground symbol's color is a darkened version of the background folder's color, and can consist of 1px lines, or filled-in areas. The foreground symbol should be centered within the folder background and take up 10x10px for the 32px icon size, and 20x20px for the 64px size. Note that for places icons, the foreground symbol does **not** cast a shadow. .. image:: /img/Breeze-icon-design-places-colorful.png :alt: Large colorful Places icons *20x20px foreground symbol in the center of a 64x64px Places icon* MIME type icons --------------- Like Places icons, MIME type icons come in four sizes: 16px, 22px, 32px, and 64px. They use the colorful style for 32px and 64px sizes, and the monochrome style for 22px and 16px sizes. Monochrome MIME type icons ~~~~~~~~~~~~~~~~~~~~~~~~~~ Like Places icons, the 16px and 22px monochrome versions of MIME type icons have no background image and consist entirely of a monochrome line-art depiction of the file type. .. image:: /img/Breeze-icon-design-19.png :alt: Small monochrome MIME type icon Monochrome MIME type icons are drawn with the primary color of the large colorful version rather than following the general monochrome icon color guidelines. .. image:: /img/Breeze-icon-design-mimetype-small.png :alt: Small monochrome document MIME types *Small MIME type icons use 1 px strokes and follow the colors of the larger versions* Colorful MIME type icons ~~~~~~~~~~~~~~~~~~~~~~~~ Like Places icons, the colorful versions consist of the monochrome icon used as a foreground symbol on top of a background. For archives, packages, compressed files, and disk images, the background is a square with a zipper going halfway down: .. image:: /img/Breeze-icon-design-mimetype-archive.png :alt: Large colorful archive MIME types For images, the background is a horizontal rectangle with the top-right corner folded over, and the fold casts a shadow: .. image:: /img/Breeze-icon-design-mimetype-image.png :alt: Large colorful image MIME types For video files, the background is a horizontal rectangle that looks like a filmstrip: .. image:: /img/Breeze-icon-design-mimetype-video.png :alt: Large colorful video MIME types For audio files, the background is a CD sleeve with a CD partially visible: .. image:: /img/Breeze-icon-design-mimetype-audio.png :alt: Large colorful video MIME types For documents and everything else, the background is a vertical rectangle with the top-right corner folded over, and the fold casts a shadow: .. image:: /img/Breeze-icon-design-mimetype-document.png :alt: Large colorful document MIME types As with the Places icons, the foreground symbol does not cast a shadow. Action and status icons ----------------------- Action and status icons come in two sizes: 16px and 22px. They always use the monochrome style. Action items should use Shade Black as much as possible: .. image:: /img/Breeze-icon-design-action.png :alt: Action icons Status icons can use a bit more color in their composition to connote status information: .. image:: /img/Breeze-icon-design-status.png :alt: Status icons Action and status icons dynamically change their colors when the user changes the system's color. To accomplish this, a special CSS stylesheet is embedded in the SVG, and then the actual shape definitions are tagged with the appropriate class. It looks like this: :: For more technical details, see `this blog post `_. Emblems ------- Emblems come in three sizes: 8px, 16px, and 22px and always use the colorful style. However, their color palette is limited to that of the monochromatic style. Unlike other icons, they are drawn with zero margins and touch the edges of the canvas. Emblem icons always have a colored background shape and a monochrome foreground symbol. Because of the extremely limited space available, it is critical that the foreground symbol be aligned to the pixel grid: .. image:: /img/Breeze-icon-design-emblem.png :alt: Pixel-perfect emblem icon 16px and 22px Emblems get a 60% opacity outline to ensure adequate contrast against whatever icon they are drawn on top of: .. image:: /img/Breeze-icon-design-emblem-16px.png :alt: 16px emblem icons *16px emblems* .. image:: /img/Breeze-icon-design-emblem-22px.png :alt: 22px emblem icons *22px emblems* 8px emblems do not have an outline, because there simply isn't enough room: .. image:: /img/Breeze-icon-design-emblem-8px.png :alt: 8px emblem icons *8px emblems*