A corporate website is audited for accessibility, the report looks respectable, and a few weeks later a customer calls because she cannot download her invoice. The contradiction usually resolves at the same point: the audit stopped at the sign-in form. Automated tools follow links and load pages that are reachable without an account; behind the login lies unknown territory for them. Since automated methods can only decide part of the WCAG criteria by machine while the rest calls for knowledgeable manual testing, a double gap opens up: too few criteria checked across too few pages. The result is audited home pages sitting next to self-service portals in which a cancellation cannot be submitted. This article shows why the German Accessibility Strengthening Act addresses the service as a whole, how to cut the audit scope of a portal cleanly, and which barriers typically only become visible behind the sign-in. The framework for that is a WCAG audit that includes the protected area from the outset.
Key takeaways
- Without credentials, automated tools cannot get past the sign-in form, and they can only decide part of the WCAG criteria by machine anyway. The protected area therefore stays unaudited twice over.
- The German act addresses the service as a whole: registration, contract management, invoice archive, support tickets and cancellation belong to it, not just the pages in front of it (Bundesfachstelle Barrierefreiheit).
- Audit scope is cut along roles, tariffs and states. An empty, a populated and a locked account behave differently and produce different findings.
- Test accounts with fabricated data instead of live data, plus a written agreement on confidentiality and deletion: that keeps an external audit clean under data protection law.
- Session timeout is the most common portal finding. WCAG 2.2.1 requires control over time limits, 2.2.6 a warning about impending data loss (W3C, WCAG 2.2).
- Behind the login the same classes of failure accumulate as in front of it. Insufficient text contrast was found on 83.9 percent (WebAIM Million, 2026) of the home pages surveyed, except that in a portal it hits paying existing customers.
The protected area is every audit's blind spot
Testing tools behave like a visitor without an account. They start on the home page, follow the links, collect HTML and evaluate it. Whatever sits behind a sign-in form simply does not exist for them: there is no link pointing to it, and even if there were, the session is missing. Yet that is exactly where the part of the offering lives that customers spend the most time in. Anyone switching an electricity tariff, reviewing an insurance policy, retrieving a medical result or searching an order history in a B2B portal spends minutes to hours behind the login, while the public part is dealt with in seconds. The ratio between audit attention and actual use is therefore inverted.
On top of that, automated methods assess only a section even where they do reach. Part of the WCAG criteria can be decided by machine; the rest calls for knowledgeable manual testing. Whether a status message is actually announced, whether the tab order follows the visible layout, or whether an alternative text says anything meaningful is decided by a person, not by a rule. Which findings can be gathered by machine and where the limit runs is set out in the article on the limits of automated testing tools. For a portal this means: even a scan with a valid session would only be the beginning, and the defensible statement comes out of manual testing.
A scan without a sign-in measures half the truth
What the act means by the service
The German Accessibility Strengthening Act has applied since 28 June 2025 (Bundesfachstelle Barrierefreiheit) to large parts of digital consumer business. Its reference point is not the individual page but the product or the service. For an energy supplier, an insurer, a clinic or a telecommunications provider, that service covers the whole path: gathering information, creating an account, entering into a contract, managing it, viewing invoices, requesting support and finally cancelling. In that chain the login is a technical step, not a legal boundary. A portal in which a cancellation cannot be submitted without a mouse does not meet the requirements for the service, even if the home page is built impeccably.
The technical reference behind it is the harmonised European standard EN 301 549 (ETSI EN 301 549), which for web content refers to WCAG 2.1 level AA and in its chapters additionally covers documents, software and support services. That, too, argues against the view that the audit scope ends at the sign-in form: an invoice PDF from the customer account falls under the documents chapter, a chat or ticketing function under support services. How closely the contract flow and operability are linked shows in retail by analogy: the article on the accessible checkout in e-commerce describes the same logic for the payment flow, which likewise only begins after a sign-in.
Registration
Creating an account, confirming an email, setting a password. This is where the requirements for accessible authentication apply, such as the ban on cognitive tests without an alternative (WCAG 3.3.8).
Contract management
Switching tariffs, changing an address, adjusting a payment method. Long forms meet short session limits here, which without a warning leads to data loss (WCAG 2.2.1, 2.2.6).
Invoice archive
Viewing and downloading documents. An untagged PDF with no reading order and no language marking is worthless for speech output (WCAG 1.3.1).
Support tickets
Reporting an issue, attaching files, reading the thread. Status changes and loading states have to be announced, otherwise the process stays invisible (WCAG 4.1.3).
Notifications
Inbox, notice banners and deadline messages. If something important is marked only by colour, part of the audience loses it (WCAG 1.4.1).
Cancellation
Leaving is as much part of the service as joining. Confirmation dialogues, focus handling and visible buttons decide whether it succeeds (WCAG 2.4.7).
These six processes form the frame a portal audit can be aligned to. They are deliberately not sorted by page but by what someone is trying to achieve. An audit that works through page by page will find contrast values and missing labels, but it misses the breaks between the steps: the jump back to the sign-in form, the focus that lands nowhere after saving, the confirmation that appears only visually. Bringing accessibility into development early saves part of these breaks; the article on accessible e-learning platforms under the German act argues along the same lines, since the same process logic applies to course areas behind a login.
Cutting the audit scope: roles, tariffs, states
A portal is not a fixed number of pages but a set of combinations. The same contract overview looks different depending on whether an account was created yesterday or has been in use for eight years, whether a tariff produces invoices at all, whether a payment is outstanding and whether the person signing in has full access or read-only rights. In B2B portals the tenant logic is added on top: a buyer sees approval steps that an ordering user does not get to see. Audit scope therefore does not come out of a page list but out of a deliberate selection along three axes: role, tariff or product, and state.
In practice that means one or two samples per axis, plus the special cases that differ strongly. A locked account shows notice banners that exist nowhere else. An empty account shows an empty state with its own semantics instead of a table. An account shortly before the end of its contract shows deadline messages with a time reference. Each of these states can bring its own barriers, and none of them can be derived from the ideal case. Where figures and contracts appear in tabular form, the test steps for accessible data tables are worth a look as well, because contract and consumption data in particular become unusable when read aloud without a header cell relationship. Which depth of testing makes sense for your offering is something we clarify in advance as part of our services.
| Aspect | Automated scan of the public pages | Audit including the login flow |
|---|---|---|
| Pages reached | only what is linked without an account | the processes through to cancellation |
| States | one default state | empty, populated, locked, in progress |
| Roles and tariffs | no distinction | one sample per role and tariff |
| Session timeout | not assessable by machine | warning, extension and data retention tested |
| Status messages | markup is read | the screen reader announcement is heard |
| Documents | PDFs mostly out of reach | invoice PDF from the archive tested |
| Outcome | list of machine-detected failures | prioritised remediation plan per process |
State belongs in the audit scope
Test accounts, test data and data protection
As soon as an external team is meant to get behind the sign-in, a technical question turns into an organisational one. Live data is the wrong route for it: an invoice archive holding the documents of real customers contains names, addresses, consumption figures and sometimes health data. The clean approach is the reverse one. The company creates test accounts, populates them with fabricated master data and generates the documents and transactions in them that are to be tested. That costs half a working day to a full one in preparation and largely defuses the data protection question, because no personal data of third parties arises during testing.
That leaves the question of the environment. A staging instance is convenient because triggering actions are possible there without risk: actually submitting a cancellation, initiating a payment, creating a ticket. It is meaningful, however, only if it matches the production state, including content, documents and third-party components. If it diverges, you are testing a portal that was not shipped in that form. In practice a combination works well: the bulk on staging, supplemented by a short cross-check in production with a purpose-created account and without triggering actions. Implementing the findings is then handled either by your team or by our accessible web development; examples can be found in our reference projects.
- One dedicated test account per role and tariff, with documented credentials
- Test data instead of live data: fabricated names, addresses, contract and invoice numbers
- Accounts in several states: newly created, populated, locked, close to contract end
- A written agreement on confidentiality, purpose limitation and deletion of the credentials
- An environment state that matches production, including content and documents
- A clear release stating which triggering actions are permitted during testing and which are not
Session timeout: warning, deadline and data retention
The most common finding behind a sign-in has to do with time. For security reasons portals end a session after a fixed period of inactivity. For people working with a screen reader, magnification, voice control or a keyboard alternative, however, filling in a long form typically takes considerably longer than it does for a practised mouse user. Someone dictating an address change with fourteen fields via voice control can exceed the limit without having been inactive at all. If the session then drops without warning, the entries are lost. WCAG 2.2.1 therefore requires a means of control for time limits: turn off, adjust or extend, with a warning and at least twenty seconds to respond (W3C, WCAG 2.2).
In addition, criterion 2.2.6 Timeouts at level AAA requires that users are warned of the duration of inactivity that can cause data loss, unless the data is preserved for more than twenty hours (W3C, WCAG 2.2). Even though AAA is not the yardstick of the German act, the criterion describes the technically clean solution: buffer the entries so that signing in again does not destroy the transaction. That re-entry is precisely the second critical point. If the session ends mid-transaction, signing in again has to work without a cognitive test; the requirements for that are described in the article on accessible authentication without CAPTCHA. And since portal forms are rarely short, it is worth looking in parallel at accessible forms and validation, because a home page alone already contains 6.9 (WebAIM Million, 2026) form fields on average - in a portal it is a multiple of that.
Two criteria, one transaction
Status changes, documents and tables in the portal
Portals are stateful, and states change frequently without a page change. A ticket moves from open to in progress, an order from checked to released, a contract from active to cancelled. Visually that happens through colour, an icon or a short notice that disappears after a few seconds. For speech output, often nothing happens at all. Success criterion 4.1.3 Status Messages requires such messages to be programmatically determinable and announced without a change of focus (W3C, WCAG 2.2). The same goes for loading states: when an invoice archive reloads, speech output has to learn that loading is under way and when the result is available. How error and status messages can be implemented cleanly is described in the article on accessible error and status messages.
The second perennial issue is documents. Invoices, contract papers and notices are delivered in portals almost exclusively as PDFs, frequently generated straight out of a billing system and without tags, without a reading order and without language marking. For speech output such a document is a wall of characters from which neither the table structure nor the amounts can be reliably extracted. Since the document is part of the service, it belongs in the audit scope and in the remediation plan; we describe the requirements and the route there under accessible PDF documents. Where genuinely reworking every document would be disproportionate, an accessible HTML view of the same data inside the portal is usually the better answer.
- Loading states without an announcement: speech output stays silent while data reloads in the background (WCAG 4.1.3)
- Status changes by colour alone: a contract moves from amber to green without the text changing (WCAG 1.4.1)
- Invoices as untagged PDFs: no structure, no reading order, no language marking (WCAG 1.3.1)
- Contract tables without a header cell relationship: figures without a column heading make no sense read aloud (WCAG 1.3.1)
- Two-factor steps with a tight deadline and automatic focus jumps between the digit fields (WCAG 2.2.1)
- Empty buttons without an accessible name, as shown by 30.6 percent (WebAIM Million, 2026) of home pages - in a portal often the icon buttons in toolbars
From finding to remediation plan
A portal audit does not end with a list of failures but with an order of work. Sensible sorting uses two dimensions: how strongly a finding blocks the transaction, and how many transactions it affects. A session timeout without a warning blocks completely and affects every transaction in the portal, so it goes to the top. Insufficient contrast in a footer blocks nothing and affects all pages, so it goes into the batch correction on the component. This sorting makes the report usable for development because it bundles effort: a single corrected form pattern typically repairs dozens of occurrences at once. In addition, a screen reader test of the core processes shows whether a correction actually holds up in practice.
After that comes ongoing assurance. Portals change more often than marketing pages, because every tariff, legal or process change lands there. A one-off audit report ages accordingly fast, which is why a recurring look at the core processes pays off; that is exactly what our accessibility monitoring is for. In parallel, the accessibility statement should name the actual scope, that is, state explicitly whether the protected area was tested and to what extent. And because a lot of portal content comes out of a content management system, it helps to keep the authoring tools accessible themselves - which is where the article on the accessible CMS under ATAG fits in.
A portal is only accessible once a cancellation can be submitted just as reliably as a contract can be signed. Anything else is an audited home page with an unaudited service behind it.
The framework is set. At the end of 2025 a good 7.8 million (Federal Statistical Office, 2026) people with a severe disability lived in Germany, corresponding to 9.4 percent (Federal Statistical Office, 2026) of the population; across the EU roughly 90 million people (European Commission) live with a disability, among them, according to a WHO estimate for the year 2002, about 1.2 million (DBSV) blind and partially sighted people in Germany. For them the protected area is not a side issue but the place where independence is decided. That there is ground to make up is suggested by the baseline in the public part: 95.9 percent (WebAIM Million, 2026) of the home pages surveyed carried detectable WCAG failures, on average 56.1 (WebAIM Million, 2026) failures per page. On 53.1 percent (WebAIM Million, 2026) of the home pages alternative texts were missing, and on 46.3 percent (WebAIM Million, 2026) there were empty links. Add to that what users expect: 71.6 percent (WebAIM Survey 2024) of the screen reader users surveyed jump through the headings first, and 88.8 percent (WebAIM Survey 2024) consider the heading levels very or somewhat useful. Anyone who wants to avoid the fine of up to 100,000 euros (BFSG, Section 37) while also reducing their own support load is well advised to start where customers spend most of their time: behind the sign-in.
Sources and Studies