Skip to main content

Frequently Asked Questions (FAQ)

General​

  • What is so special about KoliBri?
    KoliBri offers granular, easily reusable HTML compositions that are semantically accessible and decoupled from the design. Using the basic styling, which is limited exclusively to the layout, the components can be easily adapted to your own corporate design.
  • How ​​do you save with KoliBri?
    Websites/applications are implemented with different HTML elements and variants of elements. Each of these HTML structures must be semantically accessible and marked. KoliBri focuses on exactly such HTML structures and their variants and summarizes them in clearly defined components. The development teams that later reuse KoliBri can now use these components and adjust parameters to display different variants without having to think about the correctness of the HTML structure within the component. You are relieved and can focus more on the implementation of the actual technicality.
  • How ​​can you not explain KoliBri technically?
    KoliBri is for accessibility like a Thermomix® is for cooking. It makes cooking easier because you can simply choose a suitable dish (component) without having to know how to cook it exactly. The Thermomix® (KoliBri) guides you through the cooking process (parameters for different variants) and ensures that the right dish (accessible user interface) comes out at the end.
  • How ​​dependent will I be if I use KoliBri?
    If you compare KoliBri with a LEGO® set, you can simply mix the building blocks it contains with other building blocks to depict the overall application. You enter into a partial dependency (logical) in order to receive advantages in ensuring accessibility in return.
  • How ​​can I influence a component if necessary?
    KoliBri components are very restrictive to ensure accessibility and are reused through composition. Adjustments from the outside can only be made through wrapping or the Expert slot. The styling is possible via the theme concept through configuration.
  • What do I do if a component or feature is missing?
    New technically neutral components or functions are to be implemented within KoliBri. Participation in this is expressly desired and will speed up implementation.
  • What does the licensing say?
    The EUPL allows unrestricted use of the artifacts, which can be customized in a configurative way to suit one's needs. On the other hand, it forces the disclosure of changes made when copying source code from KoliBri (Copy-Left). See the for more information.

Theming and styling​

  • Who creates a theme if it doesn't already exist?
    The current situation is that the ITZBund has implemented and maintains numerous themes of its customer authorities and example themes. However, the theme concept provides that themes can be created and maintained independently. We are happy to answer any questions and can provide selective support. As soon as your own theme has been created, an independent accessibility test is necessary to ensure, for example, the contrast ratios of the color values. Themes that have been created and tested can now be used again in other projects.
  • How ​​does theming work?
    Typically, web components are created with fixed styling. KoliBri separates the semantically accessible components from the styling and provides a register method for combining them. Since the web components must always be registered (defined) in the browser, there is the option here of loading the components with a defined theme.
  • How ​​to create your own theme?
    We are always working to further simplify the creation and maintenance of themes. For example, the basic styling (pure layout) of the components from version 1.5 is used for this. You can set it up simply by creating a theme definition, e.g. with your own theme project (NPM package) using the . Our is also helpful for creating and maintaining themes.
  • Why does CSS need to be managed in JavaScript?
    KoliBri components are not styled solely using embedded CSS or the use of CSS frameworks (such as Bootstrap, Material-UI, Tailwind CSS, etc.), but about the technical setting of CSS on the component. This has the advantage that the components are independent of the external CSS. Robustness is an architectural quality objective. It is reflected in the fact that only the component itself decides on its styling.
  • Why do you need the scheme?
    KoliBri is based on a sophisticated . For example, the small schema package (@public-ui/schema) is used to define the tag names and language keys of the KoliBri components independently of the concrete implementation. This enables completely detached work with auto-completion when creating the theme, but without needing the components and their dependencies. This has advantages in some integration scenarios, such as static pages or content management systems (CMS).

Technical​

  • Why can KoliBri components really be accessible?
    The KoliBri components are designed in terms of software architecture in such a way that they can only be instrumented via properties and not via their own HTML that can be entered. This means that the components can only be controlled via the API (properties). This is a quality feature because the components cannot be manipulated from the outside. The components are very restrictive and can therefore always be accessible.
    In order to be able to break out of this restriction, there is the , which makes it possible to embed your own HTML in the component. Accessibility via the expert slot is in the hands of the expert (developer) and should only be used in exceptional cases.
  • Why are component properties sometimes named differently from HTML naming?
    In order to keep KoliBri easy to learn, the HTML naming is usually used. But even the HTML standard is not uniform in its naming across several elements (components). And that is why we have chosen uniform names for similar properties in KoliBri. See concept for more information.

Any questions?​

If you still have questions, please send us an email to .