Chips
Variations/configurability
Variant
HTML attribute
You could set the different button variants via the data-variant attribute. These could be either one of the four feedback values, or the "point of interest" stylings.
Image
Responsive images: width, height and intrinsicsize
There has been some development the latest on the new proposed intrinsicsize attribute for images, that ended with the existing and well known attributes width and height will get used to compute that intrinsicsize directly via UA-stylesheets - so the responsive images and aspect-ratio comes without any costs and leads to that it even makes more sense than ever to fill out those attributes with the basic size of your image in the first place.
For more information have a look at those articles and the standard/proposal:
- https://css-tricks.com/what-if-we-got-aspect-ratio-sized-images-by-doing-almost-nothing/
- https://css-tricks.com/do-this-to-improve-image-loading-on-your-website/ (with video)
- https://github.com/WICG/intrinsicsize-attribute/issues/16
- https://github.com/web-platform-tests/wpt/pull/18945
- https://github.com/WICG/intrinsicsize-attribute/issues/4
- https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images (in general regarding Responsive images)
Image formats
JPEG (AVIF and WebP as progressive enhancement) for photographs etc
Photographs typically fare well with lossy compression (depending on the encoder's configuration). This makes
JPEGandWebPgood choices for photographs, withJPEGbeing more compatible butWebPperhaps offering better compression. To maximize quality and minimize download time, consider providing both using a fallback withWebPas the first choice andJPEGas the second. Otherwise,JPEGis the safe choice for compatibility.
Source: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#Photographs
Next to WebP you could experiment a little bit with the new image format AVIF that promises even lower file sizes than WebP and increases in browser support.
Additionally have a look at Googles product "Guetzli", that provides great JPEG compression rates as well: https://github.com/google/guetzli/
And another tool even also resulted in fine compression rates - the main difference in between the both of them is that JPEGMini isn't available for free anymore: https://www.jpegmini.com
Attention: PNG is even also often used for pictures, even though that the special capabilities of this format like partial transparency aren't being used. This leads to much huger filesizes in most cases, as the JPEG format is capable of much better compression rates than PNG in general, so you would have to check on this aspect individually and carefully.
Partialy transparent images
Regarding images that need to have some kind of full or partial transparency, you could use either GIF (full) or PNG (most likely PNG-24 for partial) transparency.
Or use SVG masks, as this beautiful concept shows: https://github.blog/2021-01-29-making-githubs-new-homepage-fast-and-performant/#serving-the-perfect-image
Diagrams, drawings, and charts
For any image that can be represented using vector graphics,
SVGis the best choice. Otherwise, you should use a lossless format likePNG. If you do choose a lossy format, such asJPEGor lossyWebP, carefully weigh the compression level to avoid causing text or other shapes to become fuzzy or unclear.
Source: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#Diagrams_drawings_and_charts
Further image compressions
On top of the possibilities mentioned above regarding image optimizations (Google Guetzli & JPEGMini) you could as well have a look at both ImageAlpha (for PNG) and ImageOptim (for all), both available for Mac and the first both both other GUI and command-line variants and the latter as well as a webservice. Another great online tool that works entirely in the browser and doesn't even need to process your data on their servers (due to WebAssembly and some other cool stuff) is https://squoosh.app. Nowadays they additionally provide a CLI version of their software and new cool image formats, check out their version 2: https://web.dev/squoosh-v2/
Some further information on this topic are provided on this page: https://dev.to/prototyp/optimizing-images-for-the-web-an-in-depth-guide-4j7d
Accessibility
Always provide a link text
All links should have text that uniquely identifies the link target.
Source: https://www.deque.com/blog/accessibility-strategies-for-your-content-team/#:~:text=Link Text
Alt text should communicate the main point
The key is to describe what you want your audience to get out of the image rather than a simple description of what the image is.
Source: https://www.deque.com/blog/accessibility-strategies-for-your-content-team/#:~:text=Images
Using captions
For using captions it's recommended to use the <figure> and <figcaption> HTML tags - but please be aware that you additionally need to enrich those via aria-labelledby or aria-describedby attributes to ensure that assistive technologies are recognizing the linkage of those tags on Windows. It's mainly important to decide whether the figcaption HTML tags content is meant as a description or a label to choose one of those aria-* attributes correctly.
When using the down arrow, NVDA announced all the
<img>elements in turn except for the ones with empty or missingaltattributes. These were just completely ignored by the screen reader. Usingaria-labelledbyoverrode any alternate text, and usingaria-describedbyadded the ‘description’ into the alternate text. It’s interesting to note that usingaria-labelledbyalso brought images with missing or empty alternate text to the attention of NVDA.
Source: https://www.hassellinclusion.com/blog/figure-figcaption-extended-alternate-text-screen-readers/
Input
label and input elements code structure
We're using the construct of label and input elements shown below (both their order and not nesting them, as a few other frameworks do) for two good reasons:
- "Generally, explicit labels are better supported by assistive technology." - compare to the W3C spec, seems to be a WCAG criteria that for, too.
- We could easily control the styling depending on the
inputelements (pseudo-)states w/o the need for JavaScript
Auto suggestions
You could easily integrate the possibility to provide auto suggestions to your input fields via the list-attribute on the input-HTML-elements as well as adding the suggestions via the datalist-HTML-element. Please follow up within the Input - Auto Suggestions section.
Autofill
For heavily supporting the user on autofilling form fields (not only, but especially on mobile browsing) with information even already available on their devices, you could use the autocomplete attribute, as described e.g. here https://cloudfour.com/thinks/autofill-what-web-devs-should-know-but-dont/
The attribute doesn't even only take boolean values, but even also a list of specific field types, as described in the specification: https://html.spec.whatwg.org/multipage/forms.html#inappropriate-for-the-control
Form validation
Please have a look especially at the section for form validation within the overall components/forms page.
Additionally to the browser built-in pseudo-selector :user-invalid we're providing styling for the aria-invalid="true" attribute as well.
Accessibility support
For our special construct (the order of the label and input HTML tags) we need to additionaly set some further attributes on those HTML tags to better support assistive tools (screenreaders like JAWS and VoiceOver); set the aria-labelledby-attribute on the input and related id on the label as well as aria-hidden="true", e.g. like this:
<input
type="text"
class="elm-input"
placeholder="Projekt Name"
name="input01"
id="input01"
aria-labelledby="input01-label"
/>
<label class="elm-label" for="input01" aria-hidden="true" id="input01-label"
>Textlabel</label
>
We've conducted some tests with those assistive tools that lead to the conclusion that either the labels content hasn't been read out to the screenreader user on those form fields directly, but the labels content has been read again after the form field e.g. on VoiceOver. So those declarations are necessary for this kind of HTML construct, that is especially relevant for form validation and floating label functionality via CSS only.
Optionale Beschreibung
Zeile zwei
Link
Variations/configurability
Size
SCSS (recommended)
Extend one of the size SCSS placeholders in case that you don't want the default (regular): %size-Small or %size-Large
HTML attribute
You could set the different button sizes via the data-size attribute, the default is "regular" and in that case is optional.
Icons
The following three rel=* annotated links even already include an icon by default - you could enhance those by your own declarations for further patterns of linked pages.
[rel="configuration"]
[rel="messages"]
[rel="account"]
Title attribute
Advice: Don't provide title attributes to links with identical text nodes. Since the text node is already perfectly visible, this is completely redundant. It doesn't even add anything for screen readers except — in some cases — repetition.
Button vs. Link
The HTML elements for buttons and links describe a very specific type of action that is going to be taken when they are used. It is important you know when to use which, as the distinction matters:
- Use a link when you’re navigating to another place, such as: a "view all" page, "Jane Chen" profile, a page "skip link" etc.
- Use buttons when you are performing an action, such as: "submit," "merge," "create new," "upload," etc.
- An action is almost always on the same page
Source: https://www.lightningdesignsystem.com/components/buttons/#About-Buttons
Further argumentations:
- https://medium.com/simple-human/but-sometimes-links-look-like-buttons-and-buttons-look-like-links-9b371c57b3d2
- https://uxmovement.com/buttons/when-to-use-a-button-or-link/
JavaScript "links"
Never use
"javascript:" "#"or similar as the value of anhrefattribute. The purpose of thehrefattribute is to specify a URL only. If you wish to run JavaScript on an element click, use abuttoninstead.
Source: https://ebay.gitbook.io/mindpatterns/antipatterns/javascript-href
Further relevant attributes
Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a
hreflang
This attribute indicates the human language of the linked resource. It is purely advisory, with no built-in functionality. Allowed values are determined by BCP47.
ping
Contains a space-separated list of URLs to which, when the hyperlink is followed,
POSTrequests with the bodyPINGwill be sent by the browser (in the background). Typically used for tracking/analytics.
rel
Specifies the relationship of the target object to the link object. The value is a space-separated list of link types.
target
Specifies where to display the linked URL. It is a name of, or keyword for, a browsing context: a tab, window, or
<iframe>
Note: When using
target, consider addingrel="noreferrer"to avoid exploitation of thewindow.opener API. See Security concerns section.
Note: Linking to another page using
target="_blank"will run the new page on the same process as your page. If the new page is executing expensive JS, your page's performance may suffer. To avoid this userel="noopener".
aria-disabled
Instead of the disabled-attribute we're using for the button pattern to define a disabled state, we couldn't use this attribute on the link pattern, as disabled isn't a valid attribute an a HTML element, compare to e.g. the W3C ARIA documentation and the W3C spec:
Use the disabled attribute on any element that is allowed the disabled attribute in HTML.
Only use the aria-disabled attribute for elements that are not allowed to have a disabled attribute in HTML.
Please keep in mind to only include a disabled link sparly, as it's not recommended at all, compare to e.g. https://css-tricks.com/how-to-disable-links/#aa-just-dont-do-it
Ambiguous labels
Please keep in mind to use unambiguous labels: https://ebay.gitbook.io/mindpatterns/antipatterns/ambiguous-label
Link functionality caveat
The
aria-disabled="true"usespointer-events: noneto try to disable the link functionality of<a>s, but that CSS property is not yet standardized. In addition, even in browsers that do supportpointer-events: none, keyboard navigation remains unaffected, meaning that sighted keyboard users and users of assistive technologies will still be able to activate these links. So to be safe, add atabindex="-1"attribute on these links (to prevent them from receiving keyboard focus) and use custom JavaScript to disable their functionality.
Adapted from: https://getbootstrap.com/docs/4.3/components/buttons/#link-functionality-caveat
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Text Link Lorem ipsum dolor sit amet, consectetur adipisicing elit
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Text Link (disabled) Lorem ipsum dolor sit amet, consectetur adipisicing elit
Loading Indicator
Progress spinners (loading indicators) show the user that a longer-lasting action is being carried out.
Progress/Loading Indicators are used when the application executes a server request or processes data in the frontend. The component is used as soon as the execution and the resulting delay are noticeable to the user. This keeps the user aware that his or her action is being executed.
Accessibility
SVGs are often conveyed inconsistently to assistive technologies. The component’s accessibility is also highly contextual. For optimal user experience, use the aria-description prop to let assistive technology users know the purpose of the loading spinner.
aria-live and dynamic creation of html content
Using JavaScript (e.g. in context of frameworks like Angular, VueJS or React), it is possible to dynamically change parts of a page without requiring the entire page to reload — for instance, to update a list of search results on the fly, or to display a discreet alert or notification which does not require user interaction. While these changes are usually visually apparent to users who can see the page, they may not be obvious to users of assistive technologies. ARIA live regions fill this gap and provide a way to programmatically expose dynamic content changes in a way that can be announced by assistive technologies.
aria-live triggers screen readers when an element with aria-live (or text within an element with aria-live) is added or removed from the DOM. In contrast, when you unhide a hidden element, neither elements nor text are added or removed from the DOM, so the element's aria-live property doesn’t come into play.
Note that the live region needs to be present in the markup before the notification is generated or updated. If you dynamically generate both at the same time and inject them into the page, they will generally not be announced by assistive technologies.
You also need to adapt the role and aria-live level depending on the content. Further information can be found here https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
Recommendations
Do
If the application is waiting for a process, it makes sense to display an indicator in a central location.
Don‘t
An indicator should not be used to visualize the application waiting for user input.
Logo
Please find a lot of more information regarding our logo and how to use it within the Marketingportal.
Adapt logos colors (background and fill)
You could easily change the line-colors of the logo as well as the background color by defining different color values for both CSS variables:
--db-logo-color--db-logo-backgroundColor
The fallback for an undefined --db-logo-color is our DB Red (#f01414), and --db-logo-backgroundColor would fall back to transparent, which is the general background defined by brand.
Size
SCSS (recommended)
Extend one of the size SCSS placeholders in case that you don't want the default (xlarge, 58px width, 40px height): %logo-size-xsmall, %logo-size-small, %logo-size-medium, %logo-size-large or %logo-size-xlarge
HTML attribute
You could set the different button sizes via the data-size attribute, the default is xlarge and in that case is optional.
Radio
Form validation
Please have a look especially at the section for form validation within the overall components/forms page.
Additionally to the browser built-in pseudo-selector :user-invalid we're providing styling for the aria-invalid="true" attribute as well.
Select
This element doesn't fulfill the styleguides definitions especially on the option elements styling, as this isn't possible x-browser without JavaScript. If you would like to even also match those visual requirements, you would need to choose a progressive JavaScript solution on your own.
Form validation
Please have a look especially at the section for form validation within the overall components/forms page.
Additionally to the browser built-in pseudo-selector :user-invalid we're providing styling for the aria-invalid="true" attribute as well.
Textarea
Form validation
Please have a look especially at the section for form validation within the overall components/forms page.
Additionally to the browser built-in pseudo-selector :user-invalid we're providing styling for the aria-invalid="true" attribute as well.