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

Understanding permission levels

Our content management system has two primary access levels for key contributors, such as communication managers, administrators, and IT staff.

• Editors have access to make edits, but their updates require having a Publisher or Admin review them before publishing. This helps to add a layer of change management and quality control.
• Publishers have access to make and publish their own edits, create new pages, and publish news articles. However, they should not access or change menus, blocks, or navigation structures.

Core responsibilities for content managers

• Editors and publishers should focus on maintaining accurate and up-to-date page content.
• Both Editors and Publishers should limit their changes to the main “body” content area. Other website components should only be modified by web specialists.
• Publishers are responsible for reviewing Editor changes and making sure they follow best practices and accessibility rules prior to publishing them.

When to contact the web team for support

• If you're an Editor and need to publish changes.
• For changes to page structure or design.
• For changes to page titles or URLs.
• For changes to sidebar information (contact us block, etc).
• To archive pages or set up redirects.
• To update pages outside of the set of pages you were approved to edit.
• For changes requiring custom code (HTML, CSS, JavaScript). These require a review by our team to avoid security risks.
• For new features or functionality outside our standard Drupal theme.
• To create new pages, although Publishers can do this, please contact the web team first. We can guide website architecture, content organization, navigation structures, and menus to ensure users can benefit from consistent experiences throughout our websites.

File and link management

The website is 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.

PDFs

• PDFs should always be reviewed for accessibility prior to sharing them online.
• We should never host copies of educational journals that are meant for single use only. Re-sharing licensed content is copyright infringement.
• If your PDFs and files are meant for broad audiences and we hold the copyright to the content, you can find more information about adding them to the website in the Drupal manual.

Photos

• If you are adding a photo to a page, make sure that we have permission to share it either through a written consent form or a receipt that shows we have purchased the image or hold the copyright to it in some way.
• It's also best practice to resize photos for web use. Using the highest-resolution version of a photo can lead to slow loading times and web performance issues.

Links

• Remove tracking parameters from links copied from Outlook or Marketo before adding them to a webpage.
• You should 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