Hello all, as many of you would propably notice is that there is a European Accessibility Act (EAA) that will be effective from June 28 2025. For websites not compatible with it there is a fine of 5K to 250K.
The thing is that the way Wappler loads data makes almost impossible, for any of the main tools that validate WCAG Compatibility, to validate the site (even if the website is properly compatible). The only, current solution to this is to work with Wappler and other software that can create server side connections the old way. DW is not an option anymore since it is so outdated and buggy.
Is there a possibility that Wappler creates some 'old school' server behaviors that will just help to load data with PHP in the 'old' way so we overome this issue? I think for the most part we just need to load data in' aria' tags. Not to mention that this will also can be used for meta data tags that also cant be read from SEO software, FB, etc. I think that just a pure and simple query to give us the ability to load data would be great. No update, delete etc. Just the ability to load and display data.
You can make your side perfectly WCAG Compatible by following the WCAG guidelines.
The purpose of WCAG is to make it more accessible to all users and if you follow the guidelines you should be all fine.
The guidelines doesn’t require server side rendering and if you are using any third party tools to check for compatibility that require that, you shouldn’t be using them as those will provide you false results.
Hello George, yes that is true.
The thing is that the tools that are used by most of the organizations to validate the website (like Wave) cant read the data. So you understand how difficult it would be to convince the state to change the way it validates your website...
WCAG validation tools need to be able to work with dynamic websites, as there are lots of front-end frameworks in the style of "Single Page Application". From a quick search, I believe the WAVE browser extension could work, but it's not a standalone tool, I'm guessing you need a standalone tool?
Yes I agree with you. This is not only about WCAG compatibility. There are many tools even very established ones (like SEMrush), that will give you false optimization score. This has always been an issue. And yes I agree that the other tools should evolve. The way Wappler loads data etc is exceptional. It is just that most of the market (from the Marketing aspect of it) is not yet ready since they dont have the right tools. We end up creating websites with wp, webflow, wix, just for this, and it is just a shame because Wappler is so much more superior than these ones.
These days, I’m using Next.js to consume the APIs created in Wappler. It’s quite easy to use Next.js, especially with tools like Cursor or others that do most of the work for you. This has always been — and will always be — a challenge for Wappler. They don’t seem to understand that nowadays, SSR (Server-Side Rendering) is essential, and we have several tools in the market that help with this:
Next.js (React) The most popular option for SSR with React.Supports SSR, SSG, ISR, and API routes.Highly scalable and integrates well with Vercel.Excellent for SEO and performance.
Nuxt.js (Vue.js) The Vue equivalent of Next.js.Supports SSR and SSG.Easy to use with simple configuration.
SvelteKit A framework for Svelte with SSR support.Extremely fast and modern.A great choice for those seeking performance and simplicity.
Remix Focused on SSR and using standard web APIs.More opinionated than Next.js.Excellent performance with route-based rendering.
I’ve always dreamed of having something like this in Wappler, but so far, it hasn’t happened.
Here’s a tip: if your site is in PHP, you can use a small piece of code at the top of the page to fetch data from the API, so you can use PHP code naturally — I used to do that in my older websites.
$apiUrl = 'https://yourapi.com/endpoint';
$response = file_get_contents($apiUrl);
$data = json_decode($response, true);
// Now you can use $data in your PHP page
?>
type or paste code here
That is a problem with those so-called main tools, they do not understand JavaScript.
As @George has stated, just follow the guidelines and all is well!
What are the guidelines?
These are principles that a web developer should already know. But to help out:
Ensuring <html> has a valid lang attribute.
Correct <title> and proper heading structure.
Clear and consistent navigation landmarks (header, nav, main, footer).
Touch-friendly, keyboard-navigable elements.
Color contrast and scalable font settings.
ARIA roles/labels where needed.
Screen reader visibility/hiding techniques.
A. Items 1 and 2 should be performed when starting a new project. This is easily done
B. I have often mentioned the importance of item 3, resulting in a pleasing <main> element as the default element in NodeJS. As a further issue worth mentioning, see the following video
C. Items 4,5 and 6 are usually handled by the Bootstrap framework. It is therefore prudent to let Wappler handle the code and not hand code if these items are not your forte. In case you do persist in changing the code, using the Accessibility Mode can assist when dealing with item 5.
D. For item 7, there are several techniques to control the visibility of content for screen readers while maintaining accessibility. Here are some common methods:
ARIA Attributes: Using aria-hidden="true" hides content from screen readers while keeping it visible to sighted users.
CSS Techniques:
display: none; or visibility: hidden; hides content from both sighted users and screen readers.
text-indent: -10000px; moves text off-screen but keeps it readable for screen readers.
.sr-only class positions content off-screen while keeping it accessible to assistive technologies.
.visually-hidden class hides content visually but keeps it accessible to screen readers.
Empty alt Attributes: For decorative images, setting alt="" ensures they are ignored by screen readers.
Role Attributes: Using role="presentation" or role="none" for decorative elements prevents them from being announced.
Tabindex Manipulation: Setting tabindex="-1" removes non-focusable content from keyboard navigation.
Each technique serves a different purpose, so choosing the right one depends on whether you want to hide content visually, from screen readers, or both.
Having said that, I decided to ask GPT-4.1 to have a look at a random site that I had created in a previous era. This is the reply:
Your main layout file is now enhanced for accessibility readiness:
Language attribute is set in <html>.
Head contains proper <title> and charset.
Semantic landmarks: <header>, <nav>, <main> (role="main", id="content"), and <footer>.
Added a skip-to-content link for keyboard users.
If navigation/search is present, ARIA roles/labels or role="search" are included.
Decorative icons are aria-hidden and all images have meaningful alt text.
Heading structure is logical.
Interactive non-form elements are focusable if needed.
Hello @ben.
The thing is that without SSR as @AdrianoLuiz mentions, many very established tools can not read the data from the website. It is not a matter of if the website is propelrly set up regarding ARIA, SEO, etc, during development. It is that that some very established tools that marketers, goverment organizations use to validate the website, get false results. Imagine if a client of yours has applied for a program to take money from the state for a WCAG 2.1 compatible website and he gets rejected, because the tool that the state uses, gives false results because of the lack of SSR. Imagine having to collaborate with an agency and when they audit the website with their tools, to get false results, that the website is not SEO optimized and you got paid for this. What I am trying to explain is not a matter of not following the guidelines during deveelopment, rather than many established tools used by agencies, the state can not validate the website because of lack of the SSR.
But what content exactly that is not in your html now do you need to render server side? Most of your content is already in your html and don’t need any server side rendering.
And for the few things that can be only rendered server side you can use the server side data bindings and rendering that we already have in NodeJS and php.
Btw just to recap. I love Wappler ok? I consider it one of the most awesome software for development. But I have many times encountered this issue. Even with a simple FB share, you get results like this
and not the actual content.
Maybe it is something I am missing in Wappler and not following the right way, and I will be more than happy if this is the case.
Ben... it is not a matter if the website is properly developed. It is what, the end user that will decide if your website is valid or not, will actually get as a result from the tool he/she is using...
They will never dig into the code and check the details. They will just consider the results (of the tool they use) as valid and they will move on...
