Transcript HTML format
QA for MIMAS A Case Study Anne McCombe MIMAS [email protected] http://www.mimas.ac.uk Where we were in June 2002 Many people managing “own” web sites, each with own way of doing things • Main MIMAS web site • Different services • Different users • Different appearance • Different standards EIB MIMAS Services (June 2002) People Each service managed differently: • Small teams putting up content, rarely for more than one service • Several programmers – each doing things in their own way • Different managers focusing on their own services • Central MIMAS web site managed by another small team Projects have web sites too, but no-one to maintain them. How we manage web content Over half our staff update web pages, in various ways, on Unix server or PC: • Logon to Unix server and edit with emacs or vi • Live site, test site (shared) or own test site • Copy to PC, edit and FTP back • Use Dreamweaver Each service is responsible for its own web site. We do not have a single “web master”. Accessibility legislation The Goal: • To be compliant with WAI guidelines, level 1 for existing sites, level 2 for new sites, by 1 September 2002. How: • Raise staff awareness of the issues • Develop skills of web editors • Set up a team to coordinate, motivate, advise ACE team Accessibility Compliance Exercise team • Each section to be represented Important to have support of all the managers • Variety of skills and experience Accessibility champion Programmer Generalist Enthusiast Coordinator Scoping the Project ACE team: • Constructed a list of services or sets of web pages, maintained by various people • Each was contact for a number of services • Met fortnightly to monitor progress Service web editors: • Check their pages • Plan how to make them accessible • Estimate timescales Documentation Staff web area set up to make available: • • • • • • • • • Accessibility Policy Accessibility progress of each service How to get started, how to use LIFT etc. Helpful tools Training opportunities Who is responsible for what Case studies Templates Recommended Dublin Core Metadata Accessibility Policy • • • • • • • • • • Check everything against WAI guidelines Make existing sites Priority 1 compliant Make new sites Priority 2 compliant Write pages to HTML 4.01 or XHTML 1.0 Use Cascading Style Sheets Include approved Dublin Core metadata Offer online documentation in HTML Identify who looks after which sites Obtain third party statements on accessibility Accessibility statement for every service Favoured tools Audit: • Bobby, LIFT, and personal inspection • Familiarity with WAI guidelines Checking: • • • • http://validator.w3.org and equivalent bookmarklet Dreamweaver LIFT Xenu – for checking links in particular Screen reader (IBM Home Page Reader) Templates: • Copy MIMAS style template from staff web page (XHTML 1.0 and HTML 4.0) • Service template in Dreamweaver MIMAS Staff Workshops Two sessions (20 people attending) covering: • • • • Accessibility Policy HTML and XHTML validation Cascading Style Sheets and server-side includes Dublin Core Metadata • Using Dreamweaver and LIFT • Discussion on Frames, Netscape etc. • Screen reader demo External training courses: • Accessibility, Dreamweaver and CSS at MC • Netskills, JISC workshops and others Accessibility Statements MIMAS aims to make its website as usable and accessible as possible... • Request for feedback, offers of assistance etc. • Links to service accessibility pages to include: Access Keys System Requirements Plug-ins Use of Frames or Java Supplier's accessibility statement Limitations MIMAS Style Guide Construct acceptable style guide • Date formats • Common words and phrases • Fonts, logos, colours Look at current practice Compare with University guide and those of collaborating institutions, eg. ESDS Consult with staff Declare and promote the MIMAS Style Guide Update Accessibility Policy to refer to Style Guide Documenting standards New Procedure • • • • • • Small team from a few services Look for best practice in various services One person writes first draft Consultation within team, then wider to staff Refinement Announcement, and authorisation. Challenges • Finishing off • Establishing new ways of working Testing No formal procedure but: • ACE team member involved in development of new interfaces (eg. International Data, Census) • User interfaces are tested pre-release by helpdesk support team or users Browser/platform testing • Apple Mac with every conceivable browser • Unix server with Netscape 4.7 • Many PCs, many browsers Maintaining quality Testing by users and staff Spot checks • Call in the right person to help and be positive Review and update accessibility policy • Check links, refer to style guide Invite feedback from users • zetoc, Archives Hub, COPAC ACE and QA ACE team attends to Accessibility plus • Content management • Development of new sites • Documenting Procedures and Standards Service web editors: • Sites are still independently managed • We have a much more co-operative approach • New services increasingly set standards at outset, and consult others. Where we are now Every service is different but now we have an Accessibility Policy and… • • • • • • We know who is responsible for what Everyone checks their HTML always Everyone is more aware of accessibility issues Everyone includes metadata We have a procedure for archiving All services have an Accessibility web page Web sites are not developed in isolation Yet to do…possibly Document procedures, check lists for testing Unify the appearance of services Automate link checking Improve Search mechanism Experiment with a CMS for MIMAS Prepare material for more workshops Agree on everything What we have learnt Importance of: • • • • • • • • Documenting standards early Discussion and consultation Talking to everyone together in one room Being pragmatic Responding positively to constructive criticism Knowing about more than one service Ask for help when you need it Working together and sharing knowledge Services at MIMAS (June 2003)