Infopath and Section 508 Accessibility
Hey, guys! I'm building a web site for a Section 508 workgroup, and I need the site to be 100% accessible (including the administration module I'm making for the team. We're using SharePoint MOSS 2007 and I recommended using infopath to enter data into the site's database (and also to populate downloadable Microsoft Word documents). The customer claimed that InfoPath is not Section 508 compliant, which seemed odd to me because the forms can be modified to anything you want them to be (including 508 compliant).
I even found this guide to making InfoPath accessible:
http://office.microsoft.com/en-us/infopath/HA102146831033.aspx
I'm curious if there are any caveats to making accessible forms in Infopath, or if the information I've gathered is incorrect.
Thanks!
Spaz- 已移動Mike Walsh MVPMVP, 版主2009年5月15日 上午 03:59Accessibility (From:SharePoint - InfoPath Forms Services)
解答
- Most Infopath forms usually fail on the WCAG 1.0 level of accessibility at checkpoint 6.3 which restricts the use of scripting. 508 section 1194.22 (its comparison)
http://www.access-board.gov/sec508/guide/1194.22.htm#(l) is less restrictive but an equally impressive read. If you can make your form comply then well done!
On the server side, if I recall correctly forms libraries typically fail on Sect 508, 1194.22(g) Row and column headers shall be identified for data tables. If you are bypassing forms libraries and storing the generated XML from a submitted form in a DB this might be a moot concern.
Regards
John Timney (MVP)- 已標示為解答spazmospazmo 2009年5月28日 下午 04:52
所有回覆
- Moving this to the Accessibility Forum.
WSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com
Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx- 已取消標示為解答spazmospazmo 2009年5月28日 下午 04:52
- 已標示為解答spazmospazmo 2009年5月28日 下午 04:52
- 已標示為解答spazmospazmo 2009年5月28日 下午 04:52
- Most Infopath forms usually fail on the WCAG 1.0 level of accessibility at checkpoint 6.3 which restricts the use of scripting. 508 section 1194.22 (its comparison)
http://www.access-board.gov/sec508/guide/1194.22.htm#(l) is less restrictive but an equally impressive read. If you can make your form comply then well done!
On the server side, if I recall correctly forms libraries typically fail on Sect 508, 1194.22(g) Row and column headers shall be identified for data tables. If you are bypassing forms libraries and storing the generated XML from a submitted form in a DB this might be a moot concern.
Regards
John Timney (MVP)- 已標示為解答spazmospazmo 2009年5月28日 下午 04:52
- Looks good. I feel pretty confident that I can make this accessible. Additionally, the customer wants to run HiSoft on MOSS to guarantee Section 508 accessibility on every aspect of the site. I have the feeling that if we need to use something other than infopath, it will be one of many changes we will have to make; so no major decisions are hinging on this anymore.
Thanks for all the help guys!!
Tom Tolleson - Hi -
I am interested to know if the website including your forms have passed the accessibility scan by HiSoftware. As far as I know, at this point in time, InfoPath Forms Services when rendered in a browser using the XMLForm Web Part (XmlFormView) is not compliant OOB. I haven't personally tested them without the web part yet. I will be soon.
The following items are rendered with the form and when you run the default scan it will fail:
1. It produces SCRIPT tags without NOSCRIPT
2. INPUT fields without a TITLE attribute
3. IMG elements without ALT or ALT is empty.
The above confirms what John says.
EMPTY ALT
<img src="/_layouts/inc/activityanimation.gif?rev=sHmDD9LgTlytF%2FQiW0z%2Bow%3D%3D" alt="" style="display:none" />
00519 <img src="/_layouts/inc/signatureValid.png?rev=fqT6mbOhXoiXrioQ1BY9xg%3D%3D" alt="" style="display:none" />
00520 <img src="/_layouts/inc/MergedImage1.gif?rev=rDfUdiYbm0H3AHjLMLbObQ%3D%3D" alt="" style="display:none" />
00521 <img src="/_layouts/inc/MergedImage2.png?rev=MgwMZrsJcX2hRvGHEYkZlQ%3D%3D" alt="" style="display:none" />
INPUT FIELD WITH EMPTY ALT
<input id='__DialogFocusRetainer' autocomplete='off' style='width:0px;height:0px;border:none;padding:0;border:0;position:absolute' type='text' tabindex='-1' />
I don't need to show any script, you just have to View Source :-)
In summary, whether its the form or template or the way people create these things, this is a shame. We should consider at least complying with best practices in regards to rendering HTML. I personally haven't been very happy in regards to how SharePoint in general renders its pages. I am sure lots of people share these thoughts. I would like to know why its done this certain way. There has to be a reason. I would like to know why.
Thank you.

