Accessibility
You will not find a conformance statement here, for WCAG 2.2 or for any other level. A statement like that rests on an audit, and this site has not had one. What we can do is tell you, point by point, what is done, what is unverified and which barriers we already know about. And give you an address to write to if you hit one that is not on the list.
Last reviewed:
It is a description of the current state, written by the people who build the site and checked against its code. Nothing in section 2 is an intention or a plan: every point can be verified by opening the site or reading its source.
It is not the accessibility statement that Spain's Real Decreto 1112/2018 requires of public administrations. It does not follow that model and it does not open the complaints route that regulation establishes, because Factuarea is not part of the public sector. If you came looking for that document, it is not here and it should not be.
And it is not a conformance statement. Saying «conforms to WCAG 2.2 level AA» means someone went through the criteria of that level one by one and left a record of each. Nobody has done that with this site. Writing it anyway would be exactly the kind of claim the rest of these pages set out to avoid.
Eight concrete things, all of them in the code of this very site. They do not cover accessibility as a whole (no list of eight does) but they are the ones that can be checked.
Everything reachable with the Tab key draws a two-pixel outline, offset from the text and taking the colour of its surroundings. It is defined once for the whole site rather than control by control, which is what stops it from getting lost in the next button someone adds.
If your system asks for reduced motion, every scroll-triggered entrance, the drifting shapes on the home page and the line that draws itself are switched off. Content appears straight away, with no transition, and smooth scrolling goes back to being instant. It is not a toned-down version: it is zero animation.
Tailwind v4 changed its reset and buttons started showing the arrow cursor instead of the pointer. It has been put back by hand on buttons, on disclosure widgets, on form labels and on anything with a button role. A control you can press but that does not look pressable is broken for everyone, and more so for anyone who does not assume something is there.
Accordions are the browser's own, with no JavaScript state. Tables are tables, with their headers declared for both rows and columns. Closed menus are marked inert, so the Tab key does not walk into them. And the tab group on the invoicing page carries its full ARIA roles, with focus moving between tabs using the arrow keys, Home and End.
Calculators, search boxes and filters publish their result in a region that the screen reader reads as soon as it changes. Type a taxable base and the total is recalculated, and the total is spoken; you do not have to go hunting for it around the page.
Arrows, pennants, proportion bars and strokes are marked as decorative and the screen reader skips them. The rule that goes with them is the one that really matters: if a bar stands for a figure, that figure is written next to it in text.
There is not a single font size fixed in pixels anywhere on the site. All of them are relative, so browser zoom and the text size you have set in your system genuinely move them.
Spanish, English and Catalan are served at different addresses and each one declares its language in the document. All three announce each other, with a default language declared for anyone arriving without a preference. A screen reader switches voice when the language changes because the document tells it to.
The previous section is done. This one is unverified, which is not the same as broken: it is that we do not know.
There is no independent review of this site and no report to show. That is why this page does not claim a conformance level: we have nothing to back it up with.
Not with NVDA, not with JAWS, not with VoiceOver, not with TalkBack, and not systematically with any browser-and-reader combination. What we think we know about how this site sounds we infer from the markup, and correct markup does not guarantee a reading that makes sense.
axe-core is wired into the build and set to its strictest mode: a single failure stops publication. What it checks is the component library, and that library was emptied when this redesign began. The net is up and it has not caught anything yet. It will start catching again once the library is repopulated.
It has been measured where there was a specific suspicion: the blue of the logotype on the navy bands comes out at 2.92 to 1, below the minimum, which is why the symbol is white there and never its own colour. That is a spot check, not a combination-by-combination review.
They are written down here because knowing them and keeping quiet is worse than having them. None of the four is fixed as of today.
Anyone navigating by keyboard crosses the entire header on every page (the logotype, the menu entries, the language picker and the buttons at the end) before reaching the text. A skip link at the start of the document would solve it, and it is not there.
The language picker on the code block of the integrations page announces itself as a tab group, but you change tabs with the Tab key rather than the arrows, which is what anyone using a screen reader expects on finding one. Nor is the panel it shows announced as that tab's panel.
On the help page, the three fields in the box that composes the email replace the site-wide focus outline with a change of border colour. It is visible, but it has neither the same thickness nor the same contrast as everywhere else, and it is an exception that should not exist.
This redesign is being published in parts. Some addresses the menu already shows still lead to a notice saying the page does not exist. They are not indexed by search engines, but you can reach them by navigating, and running into one is disorienting.
There is no accessibility form, no separate inbox and no dedicated unit. There is one email address, and the same person who reads everything else reads it.
The address of the page, what you were trying to do and what you were using: browser, operating system and, if you use one, the screen reader or magnifier. Your message can be perfectly fine without any of that; with it, we take less time.
We reply by email. If the barrier reproduces, it gets fixed and we tell you when it is done. If we cannot reproduce it, we ask you. And if we are not going to be able to fix it soon, we say so in those words and give you, by phone or by email, the information you could not get from the site. What we will not do is stop replying.
Inside the application, the support form commits to replying within twenty-four working hours. This address does not carry that commitment in writing, but it is the only inbox there is (support, privacy and legal all go through it) so there is no separate or slower queue.
Spain's Real Decreto 1112/2018 requires the public sector to publish an accessibility statement in a specific format with its own complaints route. Factuarea is not part of the public sector and this page is not that document.
Ley 11/2023, which transposes Directive (EU) 2019/882, has since 28 June 2025 set accessibility requirements for certain products and services aimed at consumers, and exempts microenterprises providing services from them. We are not going to state here which side Factuarea falls on: we have not assessed it with legal advice, and saying so without having done it would be the same mistake as declaring a conformance we never audited.
What does not depend on either regulation is the right not to be discriminated against on grounds of disability. This page exists because of that, not because we are aware of an obligation to publish it.
The date at the top is that of the last real review of this content, not that of the last deployment of the site. It moves when something said here changes: when one of the barriers in section 4 is fixed, when a new one appears, or when there is finally an audit to report.
