In the second part of “quick accessibility audit for mObywatel, we focus on keyboard support and forms. We review, among others, the user dashboard and, as a form example, we selected the e-Deliveries mailbox setup flow – checking whether the entire process can be completed without frustration and where obstacles appear.
Note
2.1.1 Keyboard (A), 2.1.2 No Keyboard Trap (A),, 2.4.7 Focus Visibility (AA)
Możliwość obsługi strony za pomocą klawiatury i widoczny fokus są kluczowe dla osób, które nie korzystają z myszy – np. z powodu preferencji osobistych, ograniczeń ruchowych lub problemów ze wzrokiem. Każdy element interaktywny (link, przycisk, pole formularza) powinien być dostępny z klawiatury, a aktualnie wybrany element musi być wyraźnie zaznaczony. Na ogół jest on wyróżniony poprzez ramkę oraz zmianę koloru. Dzięki temu użytkownik wie, na jakim elemencie się znajduje.
Keyboard accessibility and visible focus are essential for users who do not use a mouse, including people with mobility or visual impairments. All interactive elements must be keyboard-accessible and clearly indicate focus so users can track their position on the page.
The path to the mObywatel service and the reviewed pages are keyboard-accessible—users can move through most elements, and their behavior largely follows common interaction patterns. Focus is clear and consistently visible across all tested views.
On the reviewed pages, all clickable elements are reachable via keyboard. The focus order is generally correct, with one exception described below.
Strengths:
<a> links) within a <nav>, supporting predictable keyboard operation.aria-controls="gov-menu", id="gov-menu") and communicates expanded/collapsed state (aria-expanded).To improve:
The cookie banner appears at the bottom of the page and does not block the content. Users can scroll and use links without closing it, so a focus trap is not required here. Focus trapping is used when a component behaves like a modal and needs to keep users within one interface area – so focus cannot move with Tab to content underneath until the user closes the dialog or completes the required action.
However, the issue is the order of elements in the HTML. The banner is located at the end of the document and is displayed at the bottom of the page, which means a keyboard user reaches it only after tabbing through:
Possible solutions:
Notes
On the dashboard subpage, the side navigation is implemented differently than on the service entry page – as an ARIA menu component (role="menu" and role="menuitem"). In practice, users can move between items only with Tab, without Up/Down arrow-key support expected by the WAI-ARIA menu pattern. As a result, the declared ARIA roles do not match the component’s actual behavior, which constitutes a violation of WCAG 4.1.2 Name, Role, Value.
1.3.1 Information and Relationships (A), 3.3.2 Labels or Instructions (A), 4.1.2 Name, Role, Value (A)
Form field labels allow users to understand what data to enter into each field. Thanks to them, the use of forms becomes simpler and more intuitive.
They are especially important for people who use screen readers – this technology reads labels and tells the user what kind of information is required in a given field. The lack of labels means that blind or visually impaired people cannot fill out the form on their own.
Labels should always be visible, regardless of the screen resolution and the content typed in the box.
<label> or ARIA attributes).<fieldset> i <legend>, if warranted.<form>, and fields – where appropriate – are grouped into clear sections (e.g., “Your details”, “Correspondence address”). The layout is consistent across fields: label , control and space for an error message.<fieldset> and <legend>, and action elements (“Cancel”, “Next”, “Clear field”) are implemented as <button>, so they work natively with the keyboard
aria-errormessage, and the warning text is announced by screen readers thanks to aria-live="assertive".
2.4.2 Title of page (A), 3.1.1 Language of page (A), 3.1.2 Language of part (AA)
The title of the page informs users about the content and purpose of the page, as well as helps them to orient themselves when browsing multiple tabs. It is visible in the browser bar, in search results and in the history of visited pages. For people who use screen readers, the title is of particular importance – it is the first information they hear when they enter the site. The title also affects the positioning in search engines. It should be unique to each subpage and include key information such as the subpage name and site name.
The correct designation of the language of the page (lang attribute) allows screen readers to correctly read the content in the appropriate language and tone of voice.
The absence or mislabeling of the language makes it difficult to understand the content, especially on multilingual sites. Each page should have a primary language set, and fragments in other languages should have a local designation (lang="en”, lang="de”).
html lang="pl">Is the main document language set in the page code.Each audited page correctly defines the document language.
The reviewed subpages have precisely defined titles:
<title>Get an e-Deliveries address from a public service provider - Gov.pl - Gov.pl Portal</title>
2.4.1 Bypass Blocks (A)
Skip links allow users to bypass repeated sections (such as the header or navigation menu) and jump directly to the main content. This significantly improves efficiency for people who navigate with a keyboard or use screen readers, as they move through the page sequentially.Without skip links, these users must press Tab many times to reach the main content, which slows navigation and increases effort.
Skip links are present and work correctly.
1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 1.4.4 Resize Text (AA)
A website that adapts to different screen sizes provides a comfortable experience on desktops, tablets, and smartphones. Users should not need to scroll horizontally or zoom in to read text or activate controls.
All criteria are met.
Rating: The website is accessible
The reviewed mObywatel views allow users to independently use key features with the keyboard and assistive technologies. Focus is consistently visible, the core user journey is predictable, and the e-Deliveries mailbox setup form is implemented in a mature way (semantics, grouping, validation, and messaging). The identified issues are isolated and do not block completion of the main process, but addressing them would improve interaction consistency and predictability.
<form>, sections, <fieldset>/<legend>), native buttons, and a consistent field layout.aria-invalid, aria-errormessage, aria-live).