Quick question for the Epi wizards.
Are Epi forms accessible? If not, is it easy enough to make them level AA compliant (client requires level AA WCAG compliance)?
Any help would be greatly appreciated.
I do not know it by default those are AA compliant but you can customize HTML of form elements as you wish.
We have a project where we changed all form elements.
You can take existing views as an example from "modules/_protected/EPiServer.Forms/Views/EPiServer.Forms.zip" file. Extract those views and take as an example. You can also convert those to Razor views if you want (we did it in our project).
Then you can put your modified ones into "/Views/Shared/ElementBlocks" folder but it is also possible to configure your own path by customizing view engine.
Hi, we will invest more to be AA compliant, please give us feedback or share us what you did, intend to do, ...
As Maris said, you can fully customize all view templates.
You don't need to customize the View Engine to point to your new templates.
Episerver Forms is a much better tool for making forms than xForms, but stille there is a way to go to make the forms user friendly and accessible. The most pressing issue to fullfill WCAG 2.0 AA in my ophinion, is the captcha. The captcha is difficult to use, even for people without any disabilities, because the letters in the photo is difficult to read/see. There is no way to submit a form with captcha for blind users, so therefore it should not be used. If one should feel the need for captcha, reCAPTCHA from Google is a much better choice (like the one beeing used on this site :)).
When applying checkbox and radiobuttons in Episerver Forms, you do not get a fieldset enclosing the elements, and the heading is a <span>, instead of a <legend>.
For usability and accessibility reasons, I miss the HTML5 attributes, like required and beeing able to set types on input.
Hi Aud Marie,
I create story AFORM-937 to improve Forms template, to fulfill WCAG 2.0 AA.
- Captcha (you can use reCaptcha element, which is in Forms.Samples package)
- fieldset, legend
- required attribute might be OK.
- type of input is not really easy.
The last two points might be harder to implement, because required or type of input is up to the Element (it can be custom Element we can't control) and up to the Validator apply to the Element (and it can be custom Validator as well). But we will try our best.
Any feedback about improving AA is always welcome here. Thank you.
Could you update us on the progress of this 937 ticket? Or is this publicly accessible somewhere?
Hi, sorry to say that story AFORM-937 does not have really high priority. I'll try to arrange it in May.
What's the status here? I can't find AFORM-937 listed in the bug list.
It does not have high enough priority yet. I (DevTeam) will talk with ProductOwner one more time to see any reconsideration.
FYI: AFORM-2469, released as part of today's Find packages, addresses WCAG 2.0 level AA compliance issues.
...and today, AFORM-2497 was released. This story is similar to AFORM-2469 but for dynamic content.