Editing websites using Drupal

Drupal powers many of the College of Engineering's websites, providing a robust content management system for our digital presence. To ensure our users receive the most current and accurate information, we grant contributors access to edit content relevant to their job functions.

We're excited to introduce you to our new Drupal 2.0 interface. This recent project by the CoE web team offers a more streamlined and user-friendly experience for contributors across the College of Engineering. The enhanced editing interface simplifies content management, making it easier to keep our websites up to date.

Drupal 2.0 training process

Web content management best practices

Roles and responsibilities

File and link management

Our websites are intended to share content with large, broad audiences. Our storage systems should not be used as a content repository for photos or videos. There are different solutions to sharing this type of content for smaller audiences. For more information, please email webhelp@engr.washington.edu

Optimize images

Use proper image formats and compression

• Aim for image file sizes under 500KB, as larger images negatively impact page load times and user experience.
• Use formats like WebP or optimized JPEG/PNG. Compress images to reduce file size without sacrificing quality using tools like TinyPNG.

Image dimensions recommendations:

• Homepage banners: 3600 x 900 pixels
• Article hero images: 900 pixels wide
• News items thumbnails: 750 x 500 pixels
• Headshots: 500 x 750 pixels
• Immersive story hero image: 1920 x 1080 pixels
• Full-screen images: 2560 x 1440 pixels
• Announcement content type thumbnails: 400 x 400 pixels

Use meaningful alternative text (alt text)

Every image that conveys information must have descriptive alt text. 

• Decorative images should have empty alt text (alt="") so they are ignored by assistive technologies.
• Informative images should have concise (140 characters maximum), meaningful alt text that describes the image. 
• Complex images (like charts and infographics) need a text description that screen readers can understand. 

Avoid text in images

Use real text instead of embedding text in images whenever possible, as text in images is not accessible by default.

Optimize documents

Use proper document structure

• Headings: Use built-in heading styles (e.g., Heading 1, Heading 2) to create a logical structure. 
• Lists: Use actual list formatting for bulleted or numbered lists rather than manually typing symbols.
• Tables: Use tables only for tabular data, not for layout. Ensure tables have header rows defined and use table summaries or captions when helpful.

Use accessible file formats

• PDF documents should be tagged properly to preserve structure and reading order. 
• Use accessible templates when creating documents in Word or PowerPoint.
  
  For details, see UW-IT's documents page.

Enable navigation

• Include a table of contents with clickable links for longer documents. Use bookmarks and document outlines to help users jump to sections.

Provide proper metadata 

• Include metadata such as title, author, and language to improve SEO and accessibility.

Optimize links

• Use descriptive link text that makes sense out of context, e.g., “Download the impact report” instead of “Click here.”
• Remove tracking parameters from links copied from Outlook or Marketo before adding them to a webpage.
• Always be judicious when linking to external websites outside of the UW. Are the websites regularly maintained and of good reputation? Do they have ads and other content we would not want to be linking to?

Accessibility basics

Guideline	Explanation
Use titles for web pages and documents. For details, see UW-IT's Titles page.	Don't force screen reader users to waste time going into the main content to try to guess at the topic.
Choose an easy-to-read font style and size.	Plain, standard fonts such as Times New Roman and Arial work well. Font size should be at least 12-14 points.
Use ordered and unordered lists appropriately. For details, see UW-IT's Lists page.	Lists help organize content and make it more scannable. Screen readers announce the number of items in a list and can navigate through list items, making content more accessible and easier to understand.
Write descriptive link text. For details, see UW-IT's Links and buttons page.	Write link text that makes sense out of context and is unique on the page. Avoid linking "Click here for" and directly link the text that describes what users will find. For example, use "Spring Concert Details" instead of  "Click here for event details."
Write descriptive calls to action (CTAs).	Start your calls to action with verbs like: Read, Explore, Support, Give, Participate, Sign up, Experience, Tour, etc. Be specific about the next steps for your user. For example, use "Read the article" instead of "Read more", and "Explore our strategic plan" instead of "Explore more".
Use ARIA labels to provide additional context if needed. For details, see UW-IT's ARIA page.	ARIA labels help screen readers when visible text isn't descriptive enough. Use them if you need multiple identical links (like "Read more") on one page, but skip them if your visible text is already unique and clear. Example code structure: <a href="web/accessibility" aria-label="Read more about accessibility guidelines">Read more</a>
Avoid using long URLs as link text.	When creating links, avoid using full URLs as the clickable text since screen readers must read out each character. Short URLs can sometimes be an exception. For example, “washington.edu” is easy to understand and easy to say.
Use consistent button styles. See button styles details on our design system.	Primary actions should use the default style while secondary actions use the secondary style. Use buttons as calls to action for forms, subscriptions, applications, and video playback. Keep button text concise (2-4 words) and ensure it fits on a single line.
Don’t rely on text formatting alone (e.g. bold, underlined) to convey critical information.	Screen readers generally ignore all text formatting.
Don't use color alone to convey information.	People with vision disabilities may miss important information.
Use good color contrast between text and background — at least a 4.5 to 1 ratio for normal text and 3 to 1 ratio for large text. For details, see UW-IT's Color contrast page.	People with low vision or color-blindness need high contrast colors for optimal viewing.
Create real headings, not just big, bold text. For details, see UW-IT's Headings page.	Screen readers don't recognize "fake headings," so a user can't navigate conveniently by jumping from heading to heading as they could with real headings.
Provide alt text for images. For details, see UW-IT's Images page.	The purpose of alt text is to provide a description of an image. It should effectively convey the purpose of the image.
Provide captions, transcripts and audio descriptions for media. For details, see UW-IT's Audio and video page.	These elements ensure that people with vision and/or hearing disabilities can access all information.
Create real table headings (not fake stylized headings or missing them altogether). For details, see UW-IT's Tables page.	Otherwise, screen reader users navigating through a table wouldn't know what the cell contents mean out of context, without the header being announced.
Avoid flashing or flickering content (for example, a gif of flashing lightning). For details, see UW-IT's Flashing and flickering content page.	These elements can trigger photo-epileptic seizures.

Sources: Digital Accessibility Principles and Guidelines, Deque University. IT Accessibility Checklist, University of Washington.

Additional resources

• Checking PDFs for accessibility
• Path to digital accessibility for websites
• Online digital accessibility courses for UW users
• UW’s inclusive and equitable language guide
• Deque University’s language guidelines