In today’s turbulent landscape of design, Penpot stands out with its
commitment to open-source, free unlimited access, and its unique, robust
features. An example could be its new components system that takes
another leap forward in aligning design with code. Let’s dive into how
it empowers both designers and developers to create more maintainable
and scalable design systems.f you’ve been following along with our Penpot series, you’re already
familiar with this exciting open-source design tool and how it is
changing the game for designer-developer collaboration. Previously,
we’ve explored Penpot’s Flex Layout and Grid Layout features, which bring the power of CSS directly into the hands of designers.
Today, we’re diving into another crucial aspect of modern web design and development: components.
This feature is a part of Penpot’s major 2.0 release, which introduces a
host of new capabilities to bridge the gap between design and code
further. Let’s explore how Penpot’s implementation of components can
supercharge your design workflow and foster even better collaboration
across teams.
About Components
Components
are reusable building blocks that form the foundation of modern user
interfaces. They encapsulate a piece of UI or functionality that can be
reused across your application. This concept of composability — building
complex systems from smaller, reusable parts — is a cornerstone of
modern web development.
Why does composability matter? There are several key benefits:
Single source of truth Changes to a component are reflected everywhere it’s used, ensuring consistency.
Flexibility with simpler dependencies Components can be easily swapped or updated without affecting the entire system.
Easier maintenance and scalability As your system grows, components help manage complexity.
In
the realm of design, this philosophy is best expressed in the concept
of design systems. When done right, design systems help to bring your
design and code together, reducing ambiguity and streamlining the
processes.
However, that’s not so easy to achieve when your
designs are built using logic and standards that are much different from
the code they’re related to. Penpot works to solve this challenge
through its unique approach. Instead of building visual artifacts that
only mimic real-world interfaces, UIs in Penpots are built using the
same technologies and standards as real working products.
This
gives us much better parity between the media and allows designers to
build interfaces that are already expressed as code. It fosters easier collaboration as designers and developers can speak the same language when discussing their components. The final result is more maintainable, too. Changes created by designers can propagate consistently, making it easier to manage large-scale systems.
Now,
let’s take a look at how components in Penpot work in practice! As an
example, I’m going to use the following fictional product page and
recreate it in Penpot:
To
create a component in Penpot, simply select the objects you want to
include and select “Create component” from the context menu. This
transforms your selection into a reusable element.
Create components
Creating Component Variants
Penpot
allows you to create variants of your components. These are alternative
versions that share the same basic structure but differ in specific
aspects like color, size, or state.
You can create variants by using slashes (/) in the components name, for example, by naming your buttons Button/primary and Button/secondary. This will allow you to easily switch between types of a Button component later.
Create variants
Nesting Components And Using External Libraries
Components
in Penpot can be nested, allowing you to build complex UI elements from
simpler parts. This mirrors how developers often structure their code.
In other words, you can place components inside one another.
Moreover,
the components you use don’t have to come from the same file or even
from the same organization. You can easily share libraries of components
across projects just as you would import code from various dependencies
into your codebase. You can also import components from external
libraries, such as UI kits and icon sets. Penpot maintains a growing list of such resources
for you to choose from, including everything from the large design
systems like Material Design to the most popular icon libraries.
Nesting components
Organizing Your Design System
The new major release of Penpot comes with a redesigned Assets panel,
which is where your components live. In the Assets panel, you can
easily access your components and drag and drop them into designs.
For the better maintenance of design systems, Penpot allows you to store your colors and typography as reusable styles. Same as components, you can name your styles and organize them into hierarchical structures.
Assets panel and styles
Configuring Components
One
of the main benefits of using composable components in front-end
libraries such as React is their support of props. Component props
(short for properties) allow you a great deal of flexibility in how you
configure and customize your components, depending on how, where, and
when they are used.
Penpot offers similar capabilities in a design
tool with variants and overrides. You can switch variants, hide
elements, change styles, swap nested components within instances, or
even change the whole layout of a component, providing flexibility while
maintaining the link to the original component.
Configure components
Creating Flexible, Scalable Systems
Allowing you to modify Flex and Grid layouts in component instances is where Penpot really shines. However, the power of these layout features goes beyond the components themselves.
With
Flex Layout and Grid Layout, you can build components that are much
more faithful to their code and easier to modify and maintain. But
having those powerful features at your fingertips means that you can
also place your components in other Grid and Flex layouts. That’s a big
deal as it allows you to test your components in scenarios much closer
to their real environment. Directly in a design tool, you can see how
your component would behave if you put it in various places on your
website or app. This allows you to fine-tune how your components fit
into a larger system. It can dramatically reduce friction between design
and code and streamline the handoff process.
Adjust and create overrides
Generating Components Code
As
Penpot’s components are just web-ready code, one of the greatest
benefits of using it is how easily you can export code for your
components. This feature, like all of Penpot’s capabilities, is
completely free.
Using Penpot’s Inspect panel, you can quickly
grab all the layout properties and styles as well as the full code
snippets for all components.
Code inspect
Documentation And Annotations
To
make design systems in Penpot even more maintainable, it includes
annotation features to help you document your components. This is
crucial for maintaining a clear design system and ensuring a smooth handoff to developers.
Annotations
Summary
Penpot’s
implementation of components and its support for real CSS layouts make
it a standout tool for designers who want to work closely with
developers. By embracing web standards and providing powerful, flexible
components, Penpot enables designers to create more developer-friendly designs without sacrificing creativity or control.
All
of Penpot’s features are completely free for both designers and
developers. As open-source software, Penpot lets you fully own your
design tool experience and makes it accessible for everyone, regardless
of team size and budget.
Ready to dive in? You can explore the file used in this article by downloading it and importing into your Penpot account.
As
the design tool landscape continues to evolve, Penpot is taking charge
of bringing designers and developers closer together. Whether you’re a
designer looking to understand the development process or a developer
seeking to streamline your workflow with designers, Penpot’s component
system is worth exploring.
WCAG
provides guidance for making interactive elements more accessible by
specifying minimum size requirements. In fact, the requirements are
documented in two Success Criteria: 2.5.5 and 2.5.8. Despite this, WCAG
can be difficult to achieve due to a number of misconceptions about the
requirements. In this article, Eric Bailey discusses the nuances of
interactive element sizes and clarifies what it looks like to provide
accessible interactive experiences using WCAG-compliant target sizes.
There
are many rumors and misconceptions about conforming to WCAG criteria
for the minimum sizing of interactive elements. I’d like to use this
post to demystify what is needed for baseline compliance and to point out an approach for making successful and inclusive interactive experiences using ample target sizes.
Getting right to it: When it comes to pure Web Content Accessibility Guidelines (WCAG) conformance, the bare minimumpixel sizefor an interactive, non-inline element is 24×24 pixels. This is outlined in Success Criterion 2.5.8: Target Size (Minimum).
Success Criterion 2.5.8 is level AA,
which is the most commonly used level for public, mass-consumed
websites. This Success Criterion (or SC for short) is sometimes confused
for SC 2.5.5 Target Size (Enhanced),
which is level AAA. The two are distinct and provide separate guidance
for properly sizing interactive elements, even if they appear similar at
first glance.
SC 2.5.8 is relatively new to WCAG, having been released as part of WCAG version 2.2, which was published on October 5th, 2023. WCAG 2.2 is the most current version of the standard,
but this newer release date means that knowledge of its existence isn’t
as widespread as the older SC, especially outside of web accessibility
circles. That said, WCAG 2.2 will remain the standard until WCAG 3.0 is released, something that is likely going to take 10–15 years or more to happen.
SC 2.5.5 calls for larger interactive elements sizes that are at least 44×44 pixels (compared to the SC 2.5.8 requirement of 24×24 pixels). At the same time, notice that SC 2.5.5 is level AAA (compared to SC 2.5.8, level AA) which is a level reserved for specialized support beyond level AA.
Sites that need to be fully WCAG Level AAA conformant are rare.
Chances are that if you are making a website or web app, you’ll only
need to support level AA. Level AAA is often reserved for large or
highly specialized institutions.
Making Interactive Elements Larger With CSS Padding #
The family of padding-related properties in CSS can be used to extend the interactive area of an element to make it conformant. For example, declaring padding: 4px;
on an element that measures 16×16 pixels invisibly increases its
bounding box to a total of 24×24 pixels. This, in turn, means the
interactive element satisfies SC 2.5.8.
This
is a good trick for making smaller interactive elements easier to click
and tap. If you want more information about this sort of thing, I
enthusiastically recommend Ahmad Shadeed’s post, “Designing better target sizes”.
I think it’s also worth noting that CSS margin could also hypothetically be used to achieve level AA conformance since the SC includes a spacing exception:
Spacing:
Undersized targets (those less than 24×24 CSS pixels) are positioned so
that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
[…]
The difference here is that padding extends the interactive area, while margin does not. Through this lens, you’ll want to honor the spirit of the success criterion because partial conformance is adversarial conformance. At the end of the day, we want to help people successfully click or tap interactive elements, such as buttons.
We
tend to think of targets in terms of block elements — elements that are
displayed on their own line, such as a button at the end of a
call-to-action. However, interactive elements can be inline elements as
well. Think of links in a paragraph of text.
Inline interactive elements, such as text links in paragraphs, do not need to meet the 24×24 pixel minimum requirement. Just as margin is an exception in SC 2.5.8: Target Size (Minimum), so are inline elements with an interactive target:
If
the differences between interactive elements that are inline and block
are still confusing, that’s probably because the whole situation is even
further muddied by third-party human interface guidelines requiring
interactive sizes closer to what the level AAA Success Criterion 2.5.5
Target Size (Enhanced) demands.
These may satisfy Apple and Google requirements for designing interfaces, but are they WCAG-conformant
Apple and Google — not to mention any other organization with UI
guidelines — can specify whatever interface requirements they want, but are they copasetic with WCAG SC 2.5.5 and SC 2.5.8?
It’s
important to ask this question because there is a hierarchy when it
comes to accessibility compliance, and it contains legal levels:
Human
interface guidelines often inform design systems, which, in turn,
influence the sites and apps that are built by authors like us. But
they’re not the “authority” on accessibility compliance. Notice how
everything is (and ought to be) influenced by WCAG at the very top of
the chain.
Even if these third-party interface guidelines conform
to SC 2.5.5 and 2.5.8, it’s still tough to tell when they are expressed
in “points” and “density independent pixels” which aren’t pixels, but often get conflated as such. I’d advise not getting too deep into researching what a pixel truly is.
Trust me when I say it’s a road you don’t want to go down. But whatever
the case, the inconsistent use of unit sizes exacerbates the issue.
After all, mouse cursors are for fine movements, and touchscreens are for more broad gestures, right? Not always. The thing is, devices are multimodal. They can support many different kinds of input
and don’t require a special switch to flip or button to press to do so.
A straightforward example of this is switching between a trackpad and a
keyboard while you browse the web. A less considered example is a
device with a touchscreen that also supports a trackpad, keyboard,
mouse, and voice input.
You might think that the combination of
trackpad, keyboard, mouse, and voice inputs sounds like some sort of
absurd, obscure Frankencomputer, but what I just described is a Microsoft Surface laptop, and guess what? They’re pretty popular.
There
is a difference between the two, even though they are often used
interchangeably. Let’s delineate the two as clearly as possible:
Responsive Design is about designing for an unknown device.
Inclusive Design is about designing for an unknown user.
The other end of this consideration is that people with motor control conditions
— like hand tremors or arthritis — can and do use mice inputs. This
means that fine input actions may be painful and difficult, yet
ultimately still possible to perform.
People also use more precise input mechanisms for touchscreens all the time, including both official accessories and aftermarket devices. In other words, some devices designed to accommodate coarse input can also be used for fine detail work.
I’d
be remiss if I didn’t also point out that people plug mice and
keyboards into smartphones. We cannot automatically say that they only
support coarse pointers:
My point is that a mode-based approach to inclusive design is a trap. This isn’t even about view–tap asymmetry.
Creating entire alternate experiences based on assumed input mode
reinforces an ugly “us versus them” mindset. It’s also far more work to
set up, maintain, and educate others.
It’s better to proactively accommodate an unknown number of unknown people using an unknown suite of devices in unknown ways by providing an inclusive experience by default. Doing so has a list of benefits:
A WCAG-conformant 24×24 minimum pixel size requirement for interactive elements is our industry’s best understanding
of what can accommodate most access needs distributed across a global
population accessing an unknown amount of content dealing with unknown
topics in unknown ways under unknown circumstances.
The load-bearing word in that previous sentence is minimum. The guidance — and the pixel size it mandates — is likely a balancing act between:
Setting something up that is functional enough while also
Avoiding a standard that would be impossible to broadly achieve (hence the SC 2.5.5 level AAA rating).
“This
Success Criterion defines a minimum size and, if this can't be met, a
minimum spacing. It is still possible to have very small and
difficult-to-activate targets and meet the requirements of this Success
Criterion.”
Larger interactive areas can be a good thing to strive for. This is to say a
minimum of approximately 40 pixels may be beneficial for individuals
who struggle with the smaller yet still WCAG-conformant size.
Interactive Area Sizing Is As Much An Art As It Is A Science #
We should also be careful not to overcorrect by dropping in gigantic interactive elements in all of our work. If an interactive area is too
large, it risks being activated by accident. This is important to note
when an interactive element is placed in close proximity to other
interactive elements and even more important to consider when activating
those elements can result in irrevocable consequences.
There is
also a phenomenon where elements, if large enough, are not interpreted
or recognized as being interactive. Consequently, users may
inadvertently miss them, despite large sizing.
Conformant and successful interactive areas — both large and small — require knowing the ultimate goals of your website or web app. When you arm yourself with this context, you are empowered to make informed decisions about the kinds of people who use your service, why they use the service, and how you can accommodate them.
For example, the Glow Baby app uses larger interactive elements
because it knows the user is likely holding an adorable, albeit squirmy
and fussy, baby while using the application. This allows Glow Baby to
emphasize the interactive targets in the interface to accommodate
parents who have their hands full.
Source: “Touch Targets on Touchscreens” by Neilsen Norman Group. (Large preview)
For
example, in digital maps, the position of pins is analogous to the
position of places shown on the map. If there are many pins close
together, the spacing between pins and neighboring pins will often be
below 24 CSS pixels. It is essential to show the pins at the correct map
location; therefore, the Essential exception applies.
[…]
When
the "Essential" exception is applicable, authors are strongly
encouraged to provide equivalent functionality through alternative means
to the extent practical.
Note that this exemption language is not carte blanche to make your own work an exception to the rule.
It is more of a mechanism, and an acknowledgment that broadly applied
rules may have exceptions that are worth thinking through and
documenting for future reference.
What about people who are driving in a car? People in
this context probably ought to be provided straightforward, simple
interactions that are facilitated via large interactive areas to prevent
them from taking their eyes off the road. The same could also be said
for high-stress environments like hospitals and oil rigs.
Similarly, devices and apps that are designed for children
may require interactive areas that are larger than WCAG requirements
for interactive areas. So would experiences aimed at older demographics,
where age-derived vision and motor control disability factors tend to
be more present.
Minimum conformant interactive area experiences
may also make sense in their own contexts. Data-rich, information-dense
experiences like the Bloomberg terminal come to mind here.
While you can control what components you include in a design system, you cannot control where and how they’ll be used by those who adopt and use that design system. Because of this, I suggest defensively baking accessible defaults into your design systems because they can go a long way toward incorporating accessible practices when they’re integrated right out of the box.
One option worth consideration is providing an accessible range of choices.
Components, like buttons, can have size variants (e.g., small, medium,
and large), and you can provide a minimally conformant interactive
target on the smallest variant and then offer larger, equally conformant
versions.
There
is no magic number or formula to get you that perfect Goldilocks “not
too small, not too large, but just right” interactive area size. It
requires knowledge of what the people who want to use your service want,
and how they go about getting it.
The best way to learn that? Ask people.
Accessibility
research includes more than just asking people who use screen readers
what they think. It’s also a lot easier to conduct than you might think!
For example, prototypes are a great way to quickly and inexpensively
evaluate and de-risk your ideas before committing to writing production
code. “Conducting Accessibility Research In An Inaccessible Ecosystem” by Dr. Michele A. Williams is chock full of tips, strategies, and resources you can use to help you get started with accessibility research.
