Microsoft Developer Network >
포럼 홈
>
SharePoint - Accessibility
>
Best Practices for developing accessible web sites in SharePoint 2007
Best Practices for developing accessible web sites in SharePoint 2007
I'm currently busy with an overview of Best Practices for developing accessible web sites in SharePoint 2007. After a little research I have noticed that the challenges I have faced so far are mostly XHTML/CSS/JS related and there are actually very few SharePoint 2007 specific issues: this has to do with the fact that we use very little to none of standard SharePoint controls in the Internet facing web sites we deliver.
As I would like to share the Best Practices I'm writing with the community I've been wondering whether you have tried to develop an accessible web site in SharePoint 2007 yourself and faced any challenges you would like to share. To make myself clear I'm looking for issues and challenges and not solutions in particular (these are welcome as well by the way).
모든 응답
I do have some ideas about how to deal with mechanisms for Site Definitions, architecture, forms authentication etc. How far have you come with your best practices?So far I have an outline of the subjects and items I would like to cover. Furthermore I have described the User Experience translation (transforming design into HTML+CSS+JS) phase. I'm about to begin describing creating .NET controls and then up to SharePoint itself and specific IIS-level settings.
We are at the beginning of a SharePoint project. Our biggest issue with accessibility is determining what standards to use. The WCAG 1.0 is stable but soon to be replaced by WCAG 2.0 which addresses the advances in web user experiences. It looks like the AKS is geared toward WCAG 1.0. Are there plans for udating AKS for WCAG 2.0? Also, your best practices are of great interest since we are researching the methods of making SharePoint accessible.
- Well for starters, just about every Microsoft control generates tables (priority 2 - tables should not be used for layouts). The menu control requires the use of the mouse (uses onmouseover, but not onkeydown, checkpoint 9.3).
Although WAI recommends to keep using WCAG 1.0 until 2.0 has become a standard, looking further in the future is definitely the right choice. If I'm not wrong WAI claims that WCAG 2.0 won't differ that much from the 1.0 version: a WCAG 1.0 compliant web site should require none to few changes to make it compliant with WCAG 2.0.
At this moment HiSoftware is busy with AKS v1.1 targeting Collaboration platforms. Unfortunately I haven't heard anything about any new release leveraging WCAG 2.0 compliancy. On the other hand I know that AKS will be coming at Code Plex soon and Microsoft hopes for the community support to extend AKS with new features such as WCAG 2.0.
I will try to do my best to finish the best practices as soon as possible.
- Yes, I don't want to put pressure on you
, but I really think a best practices document is wanted in the community. I think most WCM developers/architects go their 'own way' when it comes to accessiblity in MOSS and sharing your knowledge would be very valuable the them!
- Ladies and Gentleman,
Best Practices for developing accessible web sites in MOSS 2007 have been recently published by Microsoft @ Technet. The document is available @ http://blog.mastykarz.nl/go/2.
Please let me know should you have any questions or comments - I have posted on this subject in my blog (techtalkpt.wordpress.com), basically it is a 2 article guidelines to help those that need to insure level AA accessibility in MOSS . . . it is very tricky.
You can find these articles:
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
Ricardo Magalhães - I have just released ARF. This is a possible solution to creating accessible MOSS publishing sites...
http://www.spworks.co.uk/arf/accessibility.aspx
--Vince
http://blog.thekid.me.uk
Vincent Rothwell - http://blog.thekid.me.uk/default.aspx I have posted on this subject in my blog (techtalkpt.wordpress.com), basically it is a 2 article guidelines to help those that need to insure level AA accessibility in MOSS . . . it is very tricky.
You can find these articles:
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
Ricardo Magalhães
Why is it that everyone thinks "AA" means accessible?
"AA" is compliance and has very little bearing on "accessible" interface design. You want "accessible" then go build a system that adheres to WCAG 2.0 standards.
Can people use your website without using a keyboard & mouse? How about without using a screen??!? If the answer is no then your website is not accessible!
Try getting an evaluation version of Jaws (http://www.freedomscientific.com/products/fs/jaws-product-page.asp), get your devs round a table and try navigating your website with the screen switched off. Thats what blind people have to put up with...!
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog- I have to agree with Martin here, people get hung up on AA and AAA compliance when its essentially about usability. AA compliance is something to strive for!
A main concern is about how are you going to deal with the Disability Discrimination aspects. Once you hit the administration areas of most MOSS site types you always have problems as its not so good on the OTB compliance aspects.
Of the WCAG 1.0 and 2.0 guidelines, MOSS fails substantially to comply with AA, with many problems around the administration interfaces, with quite a heavy reliance on poorly labelled nested tables and you usually need to use a mouse somewhere along the way! However, that doesn't essentially mean that it isn't accessible to users when the correct assistive tools are deployed for that person, or if you have no users administering the service who require assistive technologies you don't essentially have a non-compliance issue, but you likely are not achieving AA.
There are significant design issues when creating publishing sites, but many people lose sight of the fact that MOSS isn't only about publishing sites.
Regards
John Timney (MVP) - In a similar vein, we (Content and Code) launched what we consider to be the world's first fully accessible MOSS 2007 system.. and it was an Intranet system for the RNIB (Royal National Institute for the Blind).
How did we achieve this?
First off, through a lot of hard work. Most of the user interfaces needed replacing, and we have extensively written Rendering Templates, Control Adapters, HttpModules and all manor of code to modify web.config files (through features! no manual changes!). This was pretty hard-core SharePoint dev and not to be taken lightly.
Secondly, we basically threw away 90% of the OOB master page, and all of the CSS. We decided pretty early on that CSS layout was the way to go to achieive maximum compatibility and cross browser functionality, so a hot front-end CSS developer was essential.
Fianlly (and I cannot stress this importance enough) we had access to accessibility experts (namely the "WAC" team of RNIB). They were invaluable in informing us how to structure our HTML, and what areas were ok and no-go areas. We had them in the office working alongside our developers, and getting their input while designing and building forms was fantastic.
If anyone would like to discuss exactly how this was achieved then you are more than welcome to get in touch.
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog - My current client has also invested heavily in rewriting lots of control adapters and has gone throuigh extensive levels of compliance and usability testing.
Even for those of us familar with WCAG compliance, it can take a lot of work to pick apart the rendered output of OTB MOSS and find non-compliance or things that are just plain difficult to use with screen readers like JAWS, or tools like Dragon - and then have them rectified.
I think the crux of the message here is that accessibility and MOSS is currently an expensive combination.
Regards
John Timney (MVP) - Speaking of which ... we've finally finished our latest epic.
The website for the Royal National Institute for the Blind has launched! (www.rnib.org.uk)... AAA compliant XHTML 1.1 markup, with fully accessible editing, publishing and backend ... all developed in SharePoint.
Was a job and a half, lots of control adapters and rendering templates for most of the list editing work.
I cannot tell you how much pain we had getting it all cross browser (especially IE6 which is used for a lot of the older screen-reader users like JAWs and Dragon).
But phew .. finally gone live .. I'd be happy to talk about how we implemented it. :)
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog - Hi,
I'm new to Sharepoint world and my first task is to guarantee sharepoint accessibility and I started from AKS software. I installed AKS software tools as well as TAW. Then, activate AKS on sharepoint and changed master page using AKS master pages on sharepoint publishing portal and when I run TAW I get 1 error type 1 and 4 errors type 2.
My big problem now is how to obtain level AA on publishing portal default page using AKS master page and AKS tools. What should I change there? And how?
Thanks very much,
Sérgio Hi Sergio,
I do have a few questions to start off with:
1) What are your reasons for choosing accessibility? Although any decision to make your site more accessible is admirable, some solutions are more "usable" than others, and a lot of organisations I fear only implement AA accessibility for legal reasons (and do the minimum required to pass such an audit).
2) Are you looking for AA accessibility on the front-end only (i.e. for visitors) or do you also need it for back-end (contributors administrators?)
3) What skills do you have in-house? Are you willing / expecting to do any custom development work to make your site AA?
4) What were your decisions for using AKS? Have you looked at any other tools?
Cheers
Martin Hatch
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog- Hi Martin,
AA level is for legal reasons. That's a government customer and they need AA level, which i think should be only on front end users, at least is where we are working now. I was not expecting to do custom development to reach AA but if there is not any other way to rich it i will.
I've looked only to AKS, is there any other you can recommend?
Since I'm using AKS and AKS master page, shouldn't get AA when run taw on entrance page?
Best regards,
Sérgio Fernandes - AKS will get you some of the way there, but not the whole way. If you are building a publishing site then obviously you need to make sure the Page Layouts are build to the same standards as the Master Page. If you are using OOB page layouts then that will definately not be the case!
Your biggest pain is going to be the Web Part Zones, and of course the Web parts themselves. I believe AKS includes a control-adapter to make the web part zones render accessible (in display mode anyway) but you'll need to check the web-parts out on a 1-by-1 basis.
There are also other controls on the page. I can't speak for AKS but while building the RNIB website we completely re-built the 2 navigation menu controls and the breadcrumb because they didn't quite live up to expectations.
In terms of "free" (i.e. community) products then AKS is the most well known, although there are a few others. My company is also in the process of releasing another solution (which is AAA compliant, as opposed to AA) but I cannot comment today on whether it is going to be a "paid for" product or an open source kit.
If you are still interested then please let me know. Otherwise if you want help troubleshooting AKS then the AKS community pages have pretty frequent support (they have their own support forums I believe).
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog - Hi all -
This is all exciting to see some people in the community discussing this topic. I just started looking at this few months back and stumbled on this today. I will be reading up on the material you all pointed out in this thread. However, I have a quick question I am hoping to get some guidance on. How about InfoPath Forms Services when rendered in a browser? We have several of them exposed on the internet. We are using the XmlFormView web part. These forms when rendered in the browser they include a bunch of graphics with empty ALT attributes as well as INPUT fields without any TITLEs. See below.
<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 id='__DialogFocusRetainer' autocomplete='off' style='width:0px;height:0px;border:none;padding:0;border:0;position:absolute' type='text' tabindex='-1' />
My question is, what do you do with this? How do you make this accessible with really just Section 508. We're not even talking WCAG.
Thanks in advance.
MCSD.Net, MCDBA, MCTS (WSS, MOSS) Config, Dev - Johnny,
InfoPath is by far the least accessible area of SharePoint, and it creates a lot of pain points, not just in the HTML markup but it's massive reliance on JavaScript to make things works.
Regarding the empty ALT tags you could use either an XSLT template (although the logic here would get messy, especially for Rich Text fields). The most robust approach would be some kind of filter (say an HttpModule) which uses RegEx to run through the markup and identify IMG tags for missing ALT attributes, and adds them in accordingly. TidyATL is a tool that we have used in such a module, and can "clean" a lot of HTML markup (including missing close tags and other HTML "mistakes" in the markup).
You could probably use a similar method for the missing Title attribute on <input> controls.
Ideally for improved accessibility you should also provide <labels> for each input (so that screenreader users get a better experience when moving through input controls on a form) but this would probably require a lot of XSLT work.
Hope this helps you out. I'd be keen to hear how far you get with accessible InfoPath rendering!
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog - Hi Martin,
Thanks for the speedy reply here. I appreciate it.
You provided some options for me here that I hopefully can look at soon. I've been thinking about the HTTP Module route as my last resort for a couple of days now and hearing it from you makes me think that it is a valid option. Which is good to know.
Our InfoPath forms include ToolTips on all of their controls. We reviewed pretty much all of them and ensured that's the case. But as you may have noticed, none of that actually gets rendered. I am interested to know how would a Screen Reader identify and go through the form.
As far as the XSLT discussion goes, if I understand you correctly, you are saying to run my page through an XSLT transform? This probably means linking my master page file with an XSLT style sheet, right?
Meanwhile, you gave me an idea that I would like to try out just for fun. I will try to insert a <LABEL> for that INPUT field above given that its ID will not change and see if it disappears. BTW, I am using HiSoftware for my scans. I will do that using a Content Editor Web Part.
Finally, I will keep this thread going and share any new developments for sure.
Thank you.
MCSD.Net, MCDBA, MCTS (WSS, MOSS) Config, Dev - No worries.
InfoPath forms are essentially XML files, and they use XSLT to render the user interface.
If you crack open the form using the InfoPath client you can do a "Save Source Files" which saves all of the files in the XSN. If you crack this open (I think the XSN is a CAB file ?) then you should find that each InfoPath "view" is actually an XSLT file.
Modifying this XSLT and rebuilding the template will adapt the rendering.
..
Alternatively, use your own custom webpart (or an XML Web PArt?) to pass in the InfoPath XML file and an XSLT transform.
regards
Martin Hatch
MCPD .Net Web Development
MCTS WSS 3.0 | MOSS 2007
Visit my Blog - Ok, I see where you're going with this. Good option for sure. I never thought of it before. Thanks for pointing it out.
As far as the content editor web part idea, it worked.
Next step = XSLT :-(
MCSD.Net, MCDBA, MCTS (WSS, MOSS) Config, Dev johnnyharbieh.spaces.live.com - A quick update here - Not much luck on the XSLT piece. I did try a couple of things; one is to Save the template as Source Files and the other by renaming the .xsn with .cab and extracting the files. Both produced the View as XSLT like you mentioned. The XSLT didn't have much in it. Nothing in there renders or has a reference to those 3-4 IMG elements with the empty ALT attributes.
I did some more digging in the 12 hive. I found several references to the IMGs in Core.js file found under LAYOUTS\INC folder. There is some HTML pieces in there that gets written out looks like. I modified those, but without any luck either. I think these HTML snippets are used for the dialog (Error message, Success message, Save or Save As, etc).
Not sure if I am making any sense here, anyways, back to the basics. I looked at the FormServer.aspx page responsible for hosting the IP form. It has the XMLFormView control. I am starting to think that the control is responsible for my troubles here.
L8tr
MCSD.Net, MCDBA, MCTS (WSS, MOSS) Config, Dev johnnyharbieh.spaces.live.com
