How accessible are the online application forms of German funders?

The most common barriers in application forms

The most common gaps in the online application forms of German funders are a missing autocomplete attribute on personal data fields and insufficient text contrast. In Schwerpunkt's measurement of 18 October 2026, the first affected all 48 open forms with fields for name, email, telephone or address, the second 37 of 53 open forms.

The list shows the most common barriers in the 53 open forms, ordered by the number of forms affected. In each case we measured the first page of the form, with axe-core 4.13.0 and extended checks of keyboard, focus and reflow; the method and its limits are set out below.

1. 1No valid autocomplete for name, email, telephone or address: all 48 forms with such fields, 291 of 334 fields (87 per cent) (1.3.5).
2. 2Insufficient text contrast: 37 of 53 forms (70 per cent) (1.4.3).
3. 3Missing accessible name on a field, link, button or embedded frame: 26 of 53 forms (4.1.2).
4. 4Unclear required fields: 20 of 39 forms with asterisks do not explain the asterisk, 18 do not mark the fields as required in the code (3.3.2).
5. 5CAPTCHA with a visible task such as a tick box, a picture or a sum: 14 of 53 forms (26 per cent); 22 (42 per cent) use some form of bot check.
6. 6No reflow at 320 pixels width: 14 of 53 forms; you have to scroll sideways or fields are cut off (1.4.10).
7. 7Focus not visible: 13 of 53 open forms, plus 13 of 37 sign-in pages of application portals (2.4.7).
8. 8Zoom blocked: 10 of 53 forms (19 per cent) (1.4.4).
9. 9Date cannot be entered by keyboard: 4 forms, all on the same form plugin (2.1.1).

Reading this study from the UK

The funders are German, the barriers are not. They sit in the HTML of web forms and portal sign-in pages and are judged against WCAG 2.2, the standard GOV.UK guidance tells UK public sector bodies to check their websites against (GOV.UK). A missing label, an invisible focus or a blocked zoom stops screen reader and keyboard users in the UK just as it does in Germany.

The groups of funders translate roughly as follows: a Bürgerstiftung is a community foundation, an Unternehmensstiftung a corporate foundation, and lottery funders distribute money from lotteries. Public funders are the federal government, the 16 states (Länder) and municipalities. Many forms run on shared platforms: application portals, form services and form plugins of content management systems. Wherever funders share a platform, one fix by the provider helps all of them.

The closest UK figures come from the Government Digital Service's monitoring of 1,151 public sector websites from 2022 to 2024: 77.3 per cent had contrast issues, 76.3 per cent issues with visible focus, 63.6 per cent with keyboard operation and 55.4 per cent with reflow (GDS, 2022 to 2024). GDS combines axe with manual testing across several pages per website, so its rates are higher and closer to an upper bound. Our automated rates per page are closer to a lower bound. The comparison table further down puts the figures side by side, and the section on the legal framework covers the UK rules.

Research questions

The study describes the pages measured. It does not extrapolate to all funders in Germany. Four questions guide it:

• Q1 Frequency: How often does the first page of publicly accessible online application routes of German funders show findings under WCAG 2.2 A/AA, separately for open forms and for sign-in pages of portals?
• Q2 Type of barrier: Which findings are most common, and how often do form-specific problems occur: labels, input purpose (autocomplete), required fields, CAPTCHA, keyboard and focus?
• Q3 Differences: Do the results differ by type of funder and by the platform used?
• Q4 Context: How do the results compare with official monitoring and with large surveys of the web?

State of research: what other surveys show

Official monitoring. Public sector bodies in the EU are checked regularly under Directive (EU) 2016/2102, mostly by experts by hand and across several pages per website. In Germany's second report to the European Commission, covering 2022 to 2024, none of the 7,239 websites checked was fully accessible. In the simplified monitoring only 22.31 per cent passed contrast (1.4.3), 19.08 per cent the criterion Name, Role, Value (4.1.2) and 35.43 per cent input purpose (1.3.5) (BFIT-Bund, report 2024, in German, p. 3 and table 38).

Lower Saxony checked all 50 criteria of WCAG 2.1 A/AA from 2022 to 2024 and included a form in every sample. In the first checks of 2024, 2.70 per cent passed criterion 4.1.2, 30.21 per cent input purpose and 44.33 per cent error identification (3.3.1) (state parliament paper 19/10959, in German, table 8). In Berlin only 5 of 36 checks passed input purpose in 2024 (monitoring results 2024, in German). At EU level almost all services checked are only partially compliant (SWD(2022) 410); in the accompanying consultation 50 per cent of respondents named navigation and access to forms as the main problem (accompanying study, p. 87).

UK monitoring combines axe with a manual check. Of 1,151 websites, 77.3 per cent had contrast issues, 76.3 per cent issues with visible focus, 63.6 per cent with keyboard operation and 55.4 per cent with reflow (GDS, 2022 to 2024).

Large surveys of the web. The WebAIM Million 2026 found automatically detectable WCAG failures on 95.9 per cent of one million home pages; 33.1 per cent of form inputs had no label. The Web Almanac 2025 measures with Lighthouse, which uses axe-core: only 30 per cent of websites pass the contrast check, 24.65 per cent of input fields have no accessible name (desktop), and CAPTCHAs appear on 18 per cent of websites. For non-profit organisations there is only an older count from the US: 98 of 100 home pages with a detected error (WebAIM 2019).

Online government services. The European Commission's eGovernment Benchmark checks around 14,000 websites of public services every year, including application pages, with axe, but only against eight criteria. 57 per cent violate at least one (Insight Report 2025, fig. 14); in Germany 49 per cent of the services checked met all eight (country factsheet 2026, p. 15). France publishes the compliance rates from audits of its 243 most used online procedures; by our count of the July 2026 edition, 27 of them (11.1 per cent) reach 100 per cent compliance (Observatoire, open data, in French).

The gap this study fills

• Funders: We found no survey, in Germany or internationally, of the accessibility of application forms of foundations, funding programmes or lottery funders.
• Private funders outside monitoring: Official monitoring covers only public sector bodies. Community foundations, private and corporate foundations make up 66 of the 90 pages here.
• Application pages, results per page: Large surveys measure home pages or whole websites, official checks report per website. For the online applications of German public administration under the Online Access Act (Onlinezugangsgesetz) there are no published aggregate results yet; a central testing body is being set up (IT-Planungsrat, Fachkongress 2026, in German).
• Form metrics: axe does not report a missing autocomplete attribute, because its rule only checks attributes that are present (source code of the rule). WebAIM Million and the Web Almanac do not evaluate it. To our knowledge our figure is the only published rate of missing autocomplete values in application forms.
• Open data: The results per page are available as CSV. Every figure in this study can be recalculated.

Method: selecting the pages

We measured the first page of the online application route that can be reached without an account and has input fields. For open forms this is the first page of the form, for application portals the sign-in or registration page. Anything behind the sign-in is not covered.

Selection ran in two rounds. The first started from fixed lists of large funders, without knowing in advance whether they had an online form (181 funders, 41 pages measured). Because this produced only 14 open forms, a second round looked specifically at funders likely to have an online application (511 funders, 49 pages). No funder and no page is counted twice.

From the start address a script followed at most three links related to applications. We confirmed every page found by hand and then measured it in a separate run. Basis of the selection by type of funder:

• Private foundation: in round 1 the list of the largest foundations of the Association of German Foundations (Bundesverband Deutscher Stiftungen, as of 9 February 2026, in German), every foundation that accepts applications from third parties, plus other large grant-making foundations; in round 2 the scholarship foundations for gifted students (Begabtenförderungswerke) and grant-making foundations and associations that fund projects on application.
• Corporate foundation: foundations of the DAX 40 companies, the ten largest savings banks (Sparkassen) and the five largest cooperative banks; in round 2 further savings banks, cooperative and Sparda banks and corporate foundations.
• Community foundation: in round 1 one per major city, down to about rank 60 by population; in round 2 all remaining 376 with a website from the community foundation directory of Initiative Bürgerstiftungen (in German).
• Public: federal: the federal funding database (Förderdatenbank des Bundes, in German), federal foundations and federal funds, each application portal once.
• Public: state: for each of the states (Länder) the state development bank and state foundations or state programmes, plus the regional film funds; in round 2 further state programmes.
• Public: municipal: round 2 only, funding for culture, sport, volunteering and clubs from 14 large cities and one Berlin district.
• Lottery funder: nationwide social and environmental lotteries and the Lotto and BINGO foundations of the states.

Method: measurement, definitions and validation

All measurements took place on 18 October 2026. First came the test with axe-core 4.13.0 in Playwright with headless Chromium, viewport 1,280 × 900 pixels, using only rules of WCAG 2.0, 2.1 and 2.2 at levels A and AA, including embedded frames. In the evening the extended checks followed on the same 90 pages: one visit per page, in which the script only presses the Tab key, compares image sections and narrows the viewport.

We measured politely: robots.txt respected (RFC 9309), at most one request per server per minute, our own user agent with a contact address. Nothing was clicked, filled in or submitted, no accounts were created, no CAPTCHA was touched, bot protection was not bypassed, cookie banners were not accepted, and images and fonts were not loaded.

• Entry page: the first page of an online application route that can be reached without an account and has input fields. Open form: an application form that can be filled in without signing in. Sign-in page: the sign-in or registration page of an application portal.
• Violation: a failed axe rule on a page, however many elements are affected. We count the affected elements separately.
• Finding of the extended checks: one of the seven checks in the table below is triggered. Notes, such as a focus that is only faintly visible, do not count.
• Combined rate: the share of pages with at least one axe violation or one finding of the extended checks. Every finding counts the same. A finding indicates a barrier under WCAG; it is not a verdict on the whole application process.
• Validation: before the main measurement we tested the extended checks on our demo with a form before and after (in German) and on 11 test pages of our own with known errors and error-free counterparts: 38 of 38 expectations met. We reviewed 5 pages of the sample by hand. Focus by script and focus by Tab key gave the same result for 152 of 153 fields; the difference was a measurement error in the keyboard run.
• False alarms: we fixed false alarms from the validation and from a first full run and then measured all 90 pages again. After that we reviewed every finding of the extended checks against screenshots and image sections and corrected one page by hand.

Side finding: how funders offer applications

This count applies only to the first round, because only that round started from fixed lists. Of 164 funders with a valid start address, 44 had a reachable online form or application portal, and 14 offer the application as a PDF or Word file. For 77 the script found no online form within three links, for example because applications are made informally by email or a call is closed. 29 remained unmeasured: the server did not respond (21), robots.txt excluded access (4), bot protection blocked us (3), or the application runs through a state programme already counted (1). We have not found such a count in any other source.

In the second round the route led to a measurable form page for only 49 of 511 funders, and for 28 of 376 community foundations. For most of the rest the script found no online form (305) or probably an application as a file (104).

Result 1: automated test with axe

We evaluate open forms and sign-in pages separately because they differ greatly: an open form has a median of 22 input fields, a sign-in page 2. Almost every open form has at least one violation, with a median of 2 failed rules and 7 affected elements. 3 of 53 open forms and 15 of 37 sign-in pages had no automatically detected violation.

The two rounds are close: in the first, 12 of 14 open forms had a violation, in the second 38 of 39.

The most common axe findings

The table shows on how many pages an axe rule failed, with the related WCAG criterion. 16 further rules occurred on two pages at most.

Grouped by criterion, 30 of 53 open forms (57 per cent) fail at least one rule on 4.1.2 Name, Role, Value. On 26 of them a field, link, button or embedded frame lacks an accessible name.

Result 2: extended checks by criterion

The extended checks find at least one issue on 51 of 90 pages (57 per cent), almost equally often on open forms and sign-in pages (30 of 53, 21 of 37). Two checks account for 46 of the 51 pages with a finding: invisible focus and missing reflow at 320 pixels.

• Visible focus: On 26 pages nothing visible changes when at least one field or the submit button receives focus (2.4.7). This affects 142 of 1,605 fields checked (8.8 per cent), on sign-in pages 22 of 106 (20.8 per cent). On 12 pages, 10 of them sign-in pages, not a single field shows a visible focus. Among the open forms the problem is concentrated: 4 pages account for 96 of the 120 fields affected.
• Reflow: On 23 pages you have to scroll sideways at 320 CSS pixels width (19 pages) or fields are cut off (12 pages, 48 fields) (1.4.10). Large overflows of more than 150 pixels (9 pages) come from fixed-width pages, small ones from single elements such as a bot-check widget or a signature field.
• Keyboard: On 83 of 87 testable pages the Tab key reaches every field and, where detected, the submit button (2.1.1). On 4 pages 10 fields remain unreachable, all on the same form plugin: its date fields give up focus straight away, so a date cannot be entered by keyboard. On 2 pages one control each cannot receive focus: a drop zone for files and a custom consent checkbox.
• Keyboard trap and time limit: no findings (2.1.2, 2.2.1). 4 open forms state that the form is locked or the session ends after 30 or 60 minutes without input. Whether users are warned and can extend the time could not be checked without waiting.
• Text spacing: one sign-in page whose fixed-height option tiles cut off 7 labels (1.4.12).
• Cookie dialogs: On 10 pages a cookie dialog holds the keyboard focus until a choice is made. We do not count this as a finding. For 7 of these pages the keyboard and focus values come from a second visit with the dialog hidden and not operated; 3 pages could not be tested for keyboard access.
• Notes without a finding: On 14 pages cookie banners (9) or a fixed footer bar (5) completely hide a focused field (2.4.11). A focus indicator with at least 3:1 contrast and the area of a 2-pixel outline, as the AAA criterion 2.4.13 requires, is present on 201 of 1,438 fields assessed (14 per cent).

Result 3: combined rate

Both tests together give the headline figure of this study: 52 of 53 open forms (98 per cent) and 31 of 37 sign-in pages (84 per cent) have at least one finding, 83 of 90 pages (92 per cent) in total.

The increase over axe alone comes mainly from the sign-in pages. 9 sign-in pages on which axe found nothing have a finding of the extended checks, 7 of them fields without a visible focus. These 7 pages pass everything axe checks, but anyone using a keyboard cannot see in any field where they are.

Counting only one page per platform gives the same picture: 37 of 38 open forms (97 per cent) and 21 of 25 sign-in pages (84 per cent).

Results by type of funder

Most open forms come from community foundations (34 of 53), most sign-in pages from the federal government, the states and large private foundations. The other groups are small. Differences between them may be due to chance and allow no conclusion about all funders of a type.

Public funders, which as public sector bodies may be subject to their own rules, have findings about as often in this sample (18 of 20 pages) as foundations of all kinds, that is community, corporate and private foundations together (61 of 66).

Platforms: the same findings in several places

36 of the 90 pages run on a platform we measured at least twice: application portals, form services and form plugins of content management systems. We recognised them by address patterns and shared program files and do not name them. On the same platform the same findings often repeat, for better or worse.

Platform C shows why axe alone is not enough: on all 5 sign-in pages axe finds nothing, but on all 5 no field has a visible focus. A fix by the provider therefore helps many funders at once.

So that individual platforms do not distort the result, the control calculation counts only one page per platform, the one with the median number of violations. With axe alone, 35 of 38 open forms (92 per cent) and 17 of 25 sign-in pages (68 per cent) then have a violation, combined 37 of 38 and 21 of 25.

Our own form metrics

axe checks rules for the whole page. In addition we evaluated the visible input fields in the main content, excluding search, newsletter and cookie banners: 1,538 fields in the open forms and 107 on the sign-in pages.

The 137 fields without a label are concentrated: 119 of them are in five forms, each with 20 to 26 unlabelled fields. Missing autocomplete, by contrast, affects all 48 forms with fields for personal data.

Comparison with other surveys

The table sets our figures against values from other surveys. The column “comparable?” says how far a comparison holds. As a rule, official manual audits judge each website across several pages and find more; their failure rates are closer to upper bounds. Automated rates like ours are closer to lower bounds.

Assumption for the eGovernment criteria: the benchmark's method paper names eight criteria but no axe rules. To recalculate from our CSV we mapped them to these rules: image-alt, color-contrast, document-title, link-name, html-has-lang, html-lang-valid, valid-lang, button-name, aria-hidden-focus, aria-hidden-body. This mapping is our assumption.

Answers to the research questions

• Q1 Frequency: 98 per cent of open forms and 84 per cent of sign-in pages have at least one finding, with axe alone 94 and 59 per cent.
• Q2 Type of barrier: The most common are insufficient contrast, missing names for fields and links, invisible focus and missing reflow. Among form-specific problems, missing autocomplete stands out, on 87 per cent of personal data fields. Keyboard traps and automatic time limits did not occur.
• Q3 Differences: Between types of funder, with small groups, there are no clear differences. Platforms shape the result more strongly: the same findings repeat on many or all pages of the same platform.
• Q4 Context: The rates are of the same order as large automated surveys, such as 95.9 per cent of home pages in the WebAIM Million 2026. Per criterion they are below the values of official manual audits, which test more thoroughly.

What the results mean for applicants

At the end of 2025 just over 7.8 million people in Germany had a recognised severe disability, 9.4 per cent of the population (Federal Statistical Office, in German). Counting all impairments including chronic illness, the figure was around 13 million in 2017 (Third Participation Report, in German, p. 12). How many of them apply for funding is not known. We found no reliable figure on how often people in Germany give up on an application because of barriers.

How barriers add up is shown by a user test with online job application forms of large US companies, the closest equivalent to application forms: three experienced blind screen reader users succeeded in only 50 of 90 attempts (55.6 per cent), and 34 per cent of the blocking problems involved date pickers or combo boxes (Reuschel et al. 2023). There is also an example from funding practice: one funding programme let older volunteers submit their application by post because they had problems with the online procedure (Karakayali 2018, in German, p. 38). Complex application procedures already make it harder for small organisations without staff to access funding (ZiviZ Survey 2023, in German, p. 42).

A finding does not mean that nobody can apply. It means that a group of people meets an obstacle at this point that WCAG says can be avoided:

• Invisible focus, unreachable fields: People who use a keyboard, or an assistive device that emulates keyboard input, cannot see where they are, or cannot get to a field such as the date at all (2.4.7, 2.1.1). If the field is required, the application fails at this point.
• No reflow: People who zoom in a long way have to scroll sideways on every line or see fields only partly (1.4.10).
• Weak contrast: People with low vision struggle to read hints under fields, links to the privacy notice or buttons (1.4.3).
• Missing label: A screen reader just says “edit text” without saying what to enter (4.1.2, 1.3.1).
• No autocomplete: Browsers cannot suggest name, email and address. According to the W3C this helps in particular people with memory, language or motor impairments (1.3.5).
• CAPTCHA with a task: In a survey of 1,539 screen reader users, CAPTCHA ranks first among problematic elements (WebAIM Screen Reader Survey 10). Blind participants in one study solved only 43 per cent of audio CAPTCHAs (Bigham and Cavender 2009).

Legal framework

In Germany, federal public bodies must make their websites and mobile applications accessible (section 12a BGG, in German) and publish an accessibility statement with a way to get in touch (section 12b BGG). The details are set out in the BITV 2.0, which refers to the harmonised standard EN 301 549. For services with user interaction, explicitly including forms and authentication, identification and payment processes, the “highest possible level of accessibility” should be sought (section 3 BITV 2.0, in German). Bodies of the states and municipalities are covered by state law implementing Directive (EU) 2016/2102.

BGG and BITV 2.0 apply to public bodies. The Accessibility Strengthening Act (BFSG) applies to certain products and services for consumers (section 1 BFSG, in German). Whether and which duties apply to a private foundation or an individual funder needs legal advice in each case. Either way: anyone who cannot fill in a field cannot submit the application.

In the UK, public sector bodies are covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, and GOV.UK guidance asks them to check their websites against WCAG 2.2. According to the same guidance, non-government organisations such as charities are exempt from these regulations unless they are mostly financed by public funding, provide services that are essential to the public or are aimed at disabled people; all UK service providers must make reasonable adjustments under the Equality Act 2010 (GOV.UK; Equality Act 2010, section 20 and section 29). Whether this applies to a particular grant application process is a question for legal advice in the individual case.

Recommendations for funders

The steps are ordered by impact. The first two cost little and cover the most common findings.

1. 1Check the first page yourself: Go through your form or portal sign-in using only the Tab key. Can you reach every field, and can you always see where you are (2.1.1, 2.4.7)? Then zoom to 400 per cent: does everything still work without horizontal scrolling (1.4.10)? Our guide Paper and PDF forms to accessible online forms covers the key WCAG 2.2 criteria, and our free form accessibility checker shows the most common findings that can be detected automatically.
2. 2Fix centrally: contrast (1.4.3), linked labels (4.1.2), autocomplete for personal data (1.3.5) and required for required fields, with an explanation of the asterisk (3.3.2), can usually be fixed in one place in the template.
3. 3Bot protection without a task: Check whether a method without a task for people is enough, such as a hidden field or a background check. The W3C describes the alternatives (Inaccessibility of CAPTCHA). Picture and maths tasks need an alternative (1.1.1), and signing in must not require a cognitive function test without an alternative or help (3.3.8).
4. 4Ask your provider: Ask the provider of your portal, form service or form plugin for an audit report against WCAG 2.2 level AA, including the pages behind the sign-in and the error messages. Put the requirement in writing for any new contract.
5. 5Offer a second route: State an equivalent route on the application page, such as telephone or email, and a contact for reporting barriers.
6. 6Test with people: Have the whole application, not just the first page, tested with a screen reader and magnification, by disabled people where possible. Only a manual test shows whether error messages are understandable (3.3.1, 3.3.3).
7. 7Replace PDF applications: An online form can be built to be accessible and checks entries as people fill it in; see How to move your grant application form online.

Recommendations for portal and form providers

An error in a provider's template appears at every funder that uses it. Fixes here have the widest effect.

1. 1Visible focus in the template: Every field and button needs a clear focus indicator (2.4.7), ideally with at least 3:1 contrast and the area of a 2-pixel outline (2.4.13). On one portal platform it was missing on all five sign-in pages measured.
2. 2Date fields and custom controls by keyboard: A date must be enterable without a mouse; custom checkboxes and file drop zones must receive focus and have a name (2.1.1, 4.1.2). On one form plugin this failed on 4 of 5 pages.
3. 3Allow reflow and zoom: no fixed widths, no maximum-scale or user-scalable=no in the viewport tag (1.4.10, 1.4.4). One form plugin with a shared website template blocked zoom on all five pages.
4. 4Accessible defaults: label with a for attribute, autocomplete values such as given-name, family-name, email, tel, street-address, postal-code and address-level2 (1.3.5), required on required fields, default colours with at least 4.5:1 contrast (1.4.3).
5. 5Fixed bars and session timeouts: Fixed footer or cookie bars must not completely hide a focused field (2.4.11). If you end sessions after a time limit, warn users first and offer an extension (2.2.1).
6. 6Offer bot protection without a task as the default (1.1.1, 3.3.8).
7. 7Publish an audit report: an accessibility statement or an audit report against WCAG 2.2 level AA that also covers pages behind the sign-in and error messages. This lets funders compare when choosing a provider.

Recommendations for funding bodies and the public sector

This means bodies that finance funding programmes or procure application portals, and the bodies that monitor accessibility.

1. 1Require accessibility in procurement: For application portals and form services, specify WCAG 2.2 level AA, explicitly including the pages behind the sign-in, and require an audit report before acceptance that checks keyboard, focus and error messages by hand.
2. 2Include application routes in monitoring: Official checks usually include one form in the sample, often the contact form, and report per website. Application and sign-in pages of funding portals belong in the sample on purpose, with results per criterion. For online applications of German public administration a central testing body is being set up (IT-Planungsrat, in German).
3. 3Complete the statements: Only 47.75 per cent of the websites monitored in Germany from 2022 to 2024 had an accessibility statement, and 13.42 per cent of those were entirely correct (BFIT-Bund 2024, in German, p. 6). German federal public bodies are required to publish one (section 12b BGG).
4. 4Provide an equivalent route: Allow an application route without an online form in funding guidelines for as long as barriers remain.
5. 5Open data: Publish test results per page and criterion as open data, as France does for its main online procedures (Observatoire). This makes progress measurable.

If you would like support

We check forms against WCAG 2.2 and implement the fixes, see Accessibility audit and fixes. We build online application processes for foundations and funding programmes to WCAG 2.2 level AA, see Online grant application forms.

Limitations of the study

• Automated testing covers only part. According to the vendor, axe finds on average 57 per cent of issues, counted by their number in real audits (Deque). In an independent test axe found 29 per cent of 142 different barriers (GDS tool audit, as of 2018). The extended checks close part of this gap, not all of it. No finding does not mean accessible.
• Error messages not tested. That would have meant submitting forms (3.3.1, 3.3.3). According to the vendor, axe does not detect problems with these criteria at all (Deque); in Lower Saxony only 44.33 per cent passed error identification in 2024 (state parliament paper 19/10959, in German).
• Only the first page. For portals this is the sign-in. The actual application behind it is usually longer and is not covered. Online forms whose first page shows only a start button are missing.
• One browser, no screen reader. We measured only with Chromium in desktop mode. We compared the scripted focus test against the Tab key (152 of 153 fields the same), not against assistive technology.
• Fonts and images not loaded. Widths and line breaks can differ slightly from the real rendering.
• Thresholds. “Focus visible” means any change of at least 8 out of 255 in a colour channel at the field, at its label or within a 10-pixel margin. This does not show that the indicator is clear enough; the number of inadequate focus indicators is closer to a lower bound. For reflow any overflow of more than 2 pixels counts; we did not exclude content that requires a two-dimensional layout.
• Cookie dialogs. The axe test includes cookie banners as visitors first see them. On 10 pages a dialog held the keyboard focus; for 7 we hid it with CSS in a second visit without operating it, 3 could not be tested for keyboard access. A form behind a dialog that hides the rest of the page from assistive technology could not be measured without clicking.
• Time limits. We observed for 1 to 5 minutes. We did not wait for session timeouts after 20 to 60 minutes.
• Not a representative sample. The first round covers large and well-known funders, the second was selected specifically for likely online forms. Community foundations account for 34 of the 53 open forms. The figures apply to the pages measured, not to all funders in Germany.
• Platforms. 36 pages are spread across nine platforms that occur more than once. The control calculation with one page per platform hardly changes the picture.
• Selection and reachability. Some start addresses come from our own knowledge or a web search. The federal funding database blocked our requests after a few pages with a bot check; we did not bypass it. Pages not measured may differ from those measured. The script followed at most three links, so “no form found” can also mean that the form is further down.
• Heuristics. Our own metrics and the extended checks rely on rules, for example for detecting personal data fields, the submit button or the form area, and may misclassify individual elements. Controls that cannot receive focus are more likely under-counted. We corrected by hand nine forms whose fields the script had assigned to a cookie banner.
• Snapshot. All measurements on 18 October 2026; between the axe test and the extended checks there are 3 to 16 hours. Pages change.

Data, licence and how to cite

The anonymised results are available as a CSV file, one row per page measured, 45 columns. They contain no names and no addresses, only the type of funder, the page type and an anonymous platform code. Licence: CC BY 4.0. You may use the data freely with attribution, including commercially. Dataset and report are permanently archived on Zenodo: DOI 10.5281/zenodo.23457713. The archived report and the column names are in German; this page is the English version of the report.

Suggested citation: Schwerpunkt FdG Labs UG (haftungsbeschränkt) (2026): How accessible are the online application forms of German funders? Study with research overview, version 2 of 18 October 2026, measurement of 18 October 2026. English version: schwerpunkt.tech/en/guides/accessibility-of-online-grant-application-forms-germany. Data under CC BY 4.0, https://doi.org/10.5281/zenodo.23457713.

Version 2, 18 October 2026: extended checks (keyboard, visible focus, reflow, text spacing, time limits) and state of research added, comparison table and recommendations by role new. The figures of the axe test are unchanged. Clarified: 30 open forms fail 4.1.2, on 26 of them an accessible name is missing; version 1 had described all 30 as missing names. Version 1 of 18 October 2026 contained only the axe test. English version, 19 October 2026: translation of version 2 with the same figures, plus a short section for UK readers and the UK legal position.

• lfd_nr, art_foerderer, seitentyp, plattform, messrunde: running number in random order, type of funder, open form or sign-in, platform A to I or “einzeln” (single), round 1 or 2
• verstoesse_…, betroffene_elemente_…, axe_regeln: failed axe rules and affected elements by severity, list of failed rules
• felder to sprache_gesetzt: our own form metrics on fields, labels, placeholders, autocomplete, asterisks, CAPTCHA and page language
• tastatur_… to positive_tabindex: reachability of the fields and the submit button by Tab, controls that cannot receive focus, keyboard trap or a dialog holding focus
• felder_fokus_… and absende_knopf_fokus_sichtbar: fields checked, fields without or with only faintly visible focus, hidden fields, focus on the submit button
• reflow_320_…, textabstand_abgeschnitten, zeitbegrenzung…: reflow at 320 pixels, text cut off, time limits and announced timeouts
• cookie_dialog_fuer_tastatur_ausgeblendet, befund_neue_pruefungen, befund_axe_oder_neue_pruefungen: second visit with the dialog hidden, finding of the extended checks, combined rate per page