Penn State's Web Style Guide and Web Resources Center exists to help University web developers and editors in their development and maintenance of sites. It includes, or will include, the following:
AD54 is the University's policy governing proper use of official branding on the Web. It also includes definitions of elements that will be required on all Penn State pages, guidelines on accessibility and compliance with W3C markup standards, and general best practices, among other things. The policy includes the timetable for bringing sites into greater compliance, and sets clear guidelines on what needs to be updated and when. Every web developer needs to be familiar with the provisions of AD 54.
This is all covered in AD54, but briefly the new policy merely reminds developers that, as an official trademark, the "Mark," as it's known, may not be modified in any material way, although it's use is flexible within certain limitations. On Penn State websites affected by the policy, the Mark is to be used at a fixed pixel width (27 pixels, measuring the width of the shield portion of the Mark) and must be no less than 10 pixel, or more than 15 pixels, from the upper left hand corner of a web page's active content area (not necessarily the corner of the browser window.)
For more detailied information about the University's Graphic Identity System, please go to: http://publications.psu.edu/graph_ident_system/index.html
From the policy: "All publicly accessible Web pages presenting official University information should adhere to the requirements below. This includes all pages containing information sanctioned by the University and directly related to University business or academic activities. Sites that cannot meet the requirements immediately are encouraged to do so within 6 months, but in no case longer than 1 year from the policy's effective date."
From the policy: "While the University encourages the application of the policies, defined in this document, for ease of use and consistency across all parts of the Penn State Web, adoption of this policy is not required for:
Think 'incremental change'. You don't have to change everything, all at once, and in fact the industry trend is to discourage massive site redesigns, in favor of a more incremental approach. It's easier in your users, and it's easier on you, and in the end, it all gets done in a more orderly fashion. However, you should start looking at your site with a flinty eye now, and start to make plans to implement changes.
After you've done some research into CSS/XHTML, the next thing to do is to run some validators on your site. (Check our Training Resources section for some helpful tips and some training videos.) Also, start getting comfortable with the topics of Accessibility and Web Standards. A good place to start is in this site's Resources section, located on the home page. The policy, as mentioned above, says this:
" ...Sites that cannot meet the requirements immediately are encouraged to do so within 6 months, but in no case longer than 1 year from the policy's effective date."
Any redesign, even if just section-by-section, however, would trigger the changes in AD54 and the redesign should be fully compliant by launch time. You have to ask yourself, however, if there's any reason to wait. Make plans now, run the validators now, and study up on Web Standards now. You'll be glad you did. Once you make the switch to a standards-based approach, your site(s) will be easier to maintain, easier to upgrade, and you will be making them more accessible to people with disabilities. New publicly accessible pages and sites should conform to current W3C Web markup standards. (See http://www.w3c.org and http://webstandards.psu.edu for references.)
Also from the policy:
"...Pages that validate properly to older standards do not need to be changed until that page is redesigned as part of a general or sectional redesign.
"When redesigning in the future, references to "standards" in this policy will mean those in effect at that time. Developers are expected to remain current as standards evolve.
"Existing sites: Priority for any desirable retrofitting for web standards compliance should be interpreted to mean the main and second levels. Remainder of older pages and sections would be grandfathered in and need not be reworked unless a unit chooses to, but compliance for the affected part of the site will be required when the site, or any part of the site, is redesigned..."
There are some other elements to factor into your planning, but these are the main ones.
As mentioned above, linking the process of site development at Penn State to international Web standards has several benefits to both the developer and the University.
One is that making sure that a site complies with the Worldwide Web Consortium's (http://www.w3c.org) web markup standards eliminates most problems faced by users with disabilities. This approach is a time-saver for developers who can deal with both accessibility and usability at the same time--by focusing on standards.
Second, moving to a more standards-based development approach will lead to fewer interoperability problems, which should reduce the time developers must spend testing for platform and browser incompatibilities. This will speed up the development process, reduce overall costs, and improve overall usability.
Standards also will improve Penn State Websites' usabiilty, which in itself is both a financial and ethical concern. For instance, if a site that future students use is easy to navigate, has few accessibilty problems, and lets them find and process the information they need, then this should directly affect enrollment and student retention levels. Designing for usability and using international standards can have the same result on many sites, such as those where the University's business operations provide online services. This is one of those situations where doing the right thing for our web visitors also does the right thing for us.
Yes, that's probably true, but there are two good reasons for designing for accessibility. One is that it's the right thing to do, especially for a university that has long had an express policy of inclusiveness. It makes little sense to tolerate barriers to people who have a reason to visit your site when there are cost-effective tools (the LIFT encoder, for instance) to remove most of them. The other good reason is that there is a Federal law that mandates a policy of accessible web design for the U.S. Government and any agencies or entities who receive federal funds. We're not all receiving federal funds, of course, but some parts fo the University do. This is just a way to make a first good-faith effort to make accessibility design part of official University policy.
Use your best judgement for now, but make sure you stay current as validators improve. Keep testing. Be relentless. It's true that validator results may not always be reliable, but it's now mostly a matter of picking the best, most accessible option and adopting the attitude that we'll incorporate this approach into our total workflow, and to make it better as we go. ITS has published a good resource at http://tlt.its.psu.edu/suggestions/accessibility/ where you can study the various tips and tools they highlight to make your site more accessible.