URLs with -0

During site creation if a page is created with the same name as an existing page Drupal appends -0 to the page name. This needs to be cleaned up before the site launches. To do so, delete the original page and update the URL alias of the -0 page to remove the -0.

NOTE: if multiple pages are created with the same name the appended name will be -1 etc.

Inaccessible PDFs/Documents

All PDFs/documents hosted on KU CMS sites must be accessible. Some PDFs have only a small set of issues that can be quickly fixed. However, some will require more time and effort to remediate. You are responsible for checking and remediating them all if they are to remain on your KU CMS site. We encourage you to consider converting PDFs to webpages whenever possible.

• All PDFs/documents hosted in the KU CMS must meet accessibility standards.
• To be considered accessible for KU CMS sites, PDFs must have no issues via Adobe Acrobat’s Accessibility Checker tools.
  • This includes issues that are automatically identified by Adobe (e.g., alternative text, tagging, tables, etc.) and two issues that must be checked manually:
    1. Logical reading order
    2. Color contrast

You are responsible for checking and ensuring the accessibility of all PDFs/documents you host on your KU CMS site.

See Documents for more information, including recommended strategies and remediation help.

Accordions — Titles Should Be H3s

Accordion titles should be set as H3 headers, except in rare instances.

The default style option is H3.  The checkbox in the “Style Options” tab for each accordion sections should be set as H3, not DIV.

EXPLANATION: Screen reader users use the accordion H3 titles to navigate the page. If the accordion titles are not set as headers, a screen reader user would have to listen to everything in the section rather than being able to tab through the options before choosing what to read.

Color Contrast

All elements on your page must have sufficient color contrast to pass WCAG 2.0 guidelines at a level AA. 

Check color choices by using the WebAIM Color Contrast Checker or another accessibility color checker.

Contact Page

Academics Sites:

• A contact page is required for academic sites
• The page title should be either "Contact" or "Contact Us"
• Including the page in the menu is strongly suggested

Non-Academics Sites:

• A contact page is recommended for non-academic sites
• The page title should be either "Contact" or "Contact Us"
• Including the page in the menu is strongly suggested

All Sites:

• The page title should be either "Contact" or "Contact Us" so that the page is easily discoverable
• Provide multiple ways for a site visitor to contact you

Footer — Departmental Links

• The departmental links section of the footer (right-middle column) is intended to be used for links to affiliated websites - preferably other KU sites. 
• Prior to launch, the default departmental links must be updated or removed if not in use.
• Use no more than eight departmental links.

Footer — Contact Info

• The contact section of the footer is required and must include an email address.
• Phone number and address are strongly recommended.

Footer — KU Global Links

• The KU Global Footer Links (right-column) list is required and should not be removed. 
• The link titles (e.g., Visit KU, Apply, Give, etc.)  in have been standardized and should not be changed.
• Sites may update the link URLs to go to preferred destinations (e.g., Apply, Give).

Headers — Do Not Add Bold to Headers

Headers are already bold. When you apply additional bolding, they are too bold and no longer consistent with the branded KU Design System.

Additional bolding often occurs because content from a Drupal 7 site is copied into a Sunflower site with bold already applied. 

Headers — Empty Headers

KU CMS sites cannot contain any empty headers. Empty headers are headers without content meaning the code behind the page contains a non-breaking space (e.g., <h2>&nbsp;</h2>).

The can happen when using the "Return/Enter" key (i.e., carriage return)  to add white space. If you want extra space on a page use CSS.

Empty headers are an accessibility issue because screen reader users use headers to navigate pages. When a header is empty it can be confusing.

If you want to add additional white space, use CSS:

• See “Using Built-In Bootstrap Classes to Add White Space”
• Or, contact KU IT Web Services at webservices@ku.edu for assistance.

Headers — Present and Optimized for Search

• Headers are used to provide organizational hierarchy.
• Headers are written concisely using key words to ensure best search results.
• Search engines look at the hierarchy of information on pages based on the header classes.
• Header text is used to create search results.
  • Select header classes and write headers with searching in mind.
    • If a user is seeking your information, what are they likely to type into a search engine (e.g., Google, Yahoo, Bing)? 

Headers — Proper Order/Nesting

• Headers must be used in order: H1, H2, H3, H4, H5, H6.
  • (e.g., H3 cannot occur before an H2; H4 is properly nested under an H3).
• There can only be one H1 header on any page.

See Headers for more information, including guidelines and best practices.

Header — Classes Are Not for Aesthetics

Headers should not chosen for aesthetics.

If you would like to change the appearance of a header, use CSS to modify the way it appears. 

See “KU Custom Classes to Change Header Appearance” for more information.

Images — Alt Text

Alternative text provides a text-based description of images and graphics on the web . Alternative text is read by screen reader users and search engines. Alternative text is essential for web accessibility.

• All images must have alt text.
• Alt text should describe the image.
• There is no need to include the words "photo" or "image of".
• Alt text of graphics should contain the text in the graphic.
• Exception: Person Profile alt text should be the person's first and last names only.
  • If the Jayhawk placeholder is used the alt text should be "KU Jayhawk".

Alternative text is a required for all images in the KU CMS.

Image and Video — Quality

• All images and videos on Sunflower websites must be high-quality and high-resolution.

Images — Avoid Text in Images

• Avoid using images/graphics that contain text, whenever possible.
  • Common examples include graphs and charts, screenshots, etc.
• Sufficient alt text is required for all images.
• Put the text and graphics on the page rather than using a single image to convey the information, if possible.

Why? It is difficult to properly describe extensive/complex text and graphics for users experiencing your site via screen reader. The more information in the image, the greater your burden to use alternative text and/or description fields to properly convey the salient details of the image.

Links — Do Not Use Absolute URLs for Internal Pages

IMPORTANT: Absolute URLs on a Sunflower development site will break with the site launches

• Create links using relative URLs for internal pages
  • Relative URLs:  /yourpagename or /node/#
• Absolute URLs will break when the site goes live.
  • Absolute URLs: https://yoursitename.cms-dev.ku.edu/yourpagename
• Absolute URLs are necessary for external links, but should not be used for internal links.

How to create relative URLs?

1. Type the page title in the link field and the page will appear in a dropdown menu. Once you select the page from the dropdown menu, Drupal puts in the relative path for you.
2. If you know the specific path (e.g., /yourpagename) or node number (e.g., /node/427) for your page, you can type either of those in manually.

Links — Broken Links

• Broken Links should not exist on KU websites
• Broken links damage the user experience and tell users that the information on your site may not be reliable.
• Your site’s credibility relies on all the information on your site being accurate and up-to-date.

Links — Email

• Email links in text should expose the email address
  • bigjay@ku.edu
• Link URL formatting:
  • mailto:bigjay@ku.edu
• Buttons that link to email must indicate that the button is an email link

In Text

• In text, email links should be the email address, not the person or department's name.
  • Good Email Link Title: "Contact Big Jay at bigjay@ku.edu."
  • Bad Email Link Title: "Contact our mascot Big Jay."

In Buttons and Button-Style Links

Recommended link titles for emails in buttons and button-style links:

• Email Us
• Email [dept/org name] – Example: Email CMS Guide
• Email [individual name] – Example: Email Big Jay
• Email [dept/org title] – Example: Email Program Director
• Email [individual name, title] – Example: Email Big Jay, Program Director

Links — File Type Not in Document Link Titles

• Links to PDFs, Word, Excel, PowerPoint, Video or Audio files must include the file type in parenthesis
  • Example PDF document title (pdf)
  • Example PowerPoint document title (.ppt)
  • Example Word document title (.docx)
  • Example video file title (.mov)
  • Example audio file title (.mp3)

Reason: If a link does anything other than go to another web page, such as linking to a PDF file or launching an audio or video player, email message, or another application, make sure the link explicitly indicates what will happen.

Links — URLs as Link Titles

• Exposed URLs as link titles are not allowed in Sunflower
  • Text must be used for the link title instead
• Link titles must be descriptive and tell the user succinctly what resource they will find if they follow the link.
• Exception: Bibliographic Citations

Screen readers read the entire URL letter-by-letter. URLs are often quite long and contain information that may be confusing or irrelevant to the user, which is both unpleasant and time consuming.

Links — Drupal 7

All pages, images, and documents on your Drupal 7 site must be moved to Sunflower. Once the site goes live the links will break.

To avoid broken links and missing content, be sure to manually migrate all image and document resources to your new site.

Links — Non-Descriptive Link Titles

• Link titles must be descriptive - meaning the link title tells users what they will find if they follow the link.

Common Examples of Non-descriptive Links Titles

• Click here
• Here
• Read more
• More info
• Learn more
• Visit website
• Explore
• Watch on YouTube

Incorrect: For more information, click here.

Correct: For more information, see KU CMS Guide.

Incorrect: See KU Admissions website for more information.

Correct: See KU Admissions for more information.

Incorrect: Learn more

Correct:Our Research

Specified Non-Descriptive Link Titles Allowed on Select Sections

A feature has been added that makes it possible to use a specified list of approved non-descriptive link titles on select KU Sunflower sections. See Specified Non-Descriptive Link Titles Allowed on Select Sections for details.

Links — Phone Numbers

• Phone numbers in Sunflower must be links
• Phone URL formatting:
  • tel:+1-XXX-XXX-XXXX

Add Phone Number Links:

1. Highlight the phone number
2. Copy the phone number to your clipboard
3. Select the link icon in the WYSIWYG options
4. Type "tel:"
5. Paste the number so your link URL reads: "tel:+1-XXX-XXX-XXXX"
6. Add the “+1” in front of the number so the URL path looks like: "tel:+1-XXX-XXX-XXXX"
   1. The “+1” is the international dialing format. This ensures that no matter where they are calling from, a user will dial the correct number.
7. Save

Support: Google Web Fundamentals: Click to Call

Links — Open in Same Window

• Links should open in the same window. 

• Strongly Not Recommended: Links to sites outside the ku.edu domain may be set to open in a new window but the behavior must be consistent site-wide.

It is a standard user experience (UX) best practice for links to open in the same window to ensure that the user is not confused by unexpected browser behavior.

Menu — Requirements for Academic Sites

• Academic unit and department sites (i.e., school- and department-level sites that award degrees) are required to provide degree and application information in one of two structural options at level-one of the main menu.

For details see the navigation options on the Menu/Navigation page.

Page Titles vs. Header 1

In KU CMS - Sunflower, you must add both a page title and a Header 1 class header(H1) to each page. There should only be one H1 on a page.

As a general rule, the page title should be the same as the Header 1 (H1). However, there are times when after careful consideration your page title and H1 may need to be different.

Examples of times when a page title and H1 might differ:

• Page title: About
  
  H1: About the KU CMS

• Page title: Research
  
  H1: Our Research

Person Profile — Use Default Content Type

• Person profiles for faculty and staff must use the Person Profile content type.
• Custom profile views are allowed.
• Profile images must be 180px x 225px or larger.
  • Alt text for person profiles should be the person's first and last names.
    • Do not include the person's title. That information will be read by a screen reader as part of the page.

Tables — Include Table Headers

• Tables must have table headers either in a column header or row header.
• Table headers cannot be empty.
• Tables that are used to present data in a column and row format must be appropriately marked up in the html.

Videos — Captioning

Videos hosted on your KU CMS site must meet accessibility standards, including having accurate captions - including videos with no talking.

Captions Must Be Present on All Hosted Videos

Without exception, all videos hosted (i.e., embedded) on your KU CMS site must include captions - including videos with no talking. Additionally, to be accessible, those captions must be human-edited for accuracy (i.e., correctly transcribed including punctuation, lined up accurately with the video, and free of misspellings).

Your Videos

If you control the content, you are responsible for updating the video captioning prior to posting the video.

Someone Else's Videos

If you do not control the content, you have two options:

1. Remove the video
2. Reach out to the video owner to ask them to update the video with accurate captions.

IMPORTANT: You cannot leave an inaccessible video on a live KU CMS site while the content owner addresses accessibility issues. You must remove the video until it has been made accessible.

Captions Must Be Accurate for Accessibility

Captions must be manually reviewed and edited to correct transcript inaccuracies, punctuation, timing issues, and misspellings.

Transcripts for Videos with Little or No Talking

There are important considerations for videos with little or no talking to ensure that the captions you provide are meeting the needs of all users.

See Videos for more information about captioning.

Webforms — Approved Form Service

• Webforms collecting KU data must use Qualtrics, KU qForms, or other approved solution -or- have received an official exception from KU IT Security Office.

Webforms — Critical Data

• Webforms collecting "Critical" data per KU policy have been approved by the KU IT Security Office

Web Writing

• Users scan webpages – they do not read them
• Users want and expect clear and concise text on webpages that allows them to quickly scan the content
• Effective web writing improves the user experience — increasing the effectiveness of your website
• Effective web writing is an essential for improving your search engine optimization (SEO)

See Web Writing for information, including guidelines and best practices. 

See Web Writing Checklist for a checklist-style resource.

Accordions — Best Practices

• Accordions should contain one topic per accordion.
• The accordion title should describe the content inside.
• If you need to cover more than one topic, don't use an accordion.

Accordion Headers/Titles

• Headers/titles must be simple and clear
• Headers/titles must be descriptive of the accordion content
  • See Headers and Sub-Headers for more information, including guidelines and best practices.

Limit Accordion Groups to 3 – 4

• As a general rule, there shouldn’t be more than three or four accordions per set
  • Exceptions: frequently asked questions, instructions, etc.

Headers — Case Consistency

• We strongly recommend the use of title case for all headers.  It increases scannability and ease of use.
• Title case capitalizes the first letter of all words except prepositions, articles and conjunctions.
• All caps, underlines and italics should not be used for headers.
  • NOTE: All caps styling is part of the design in some KU Sunflower sections.
• Header case should be consistent on a page — and if possible across the site.

Title Case

Capitalize:

• Nouns
• Pronouns
• Verbs
• Adjectives
• Adverbs

Do not capitalize:

• Prepositions (e.g., in, at, to, of, on, etc.)
• Articles (e.g., an, a, the, etc.)
• Conjunctions (e.g., for, nor, but, or, yet, so, etc.)

Benefits of Title Case for Headers

• Using title case helps to set the header text apart and make it easily scannable.
• Using title case immediately signals to users that the text is a header providing context for the the copy that follows.
• Using sentence case for headers may cause the user to have to work to determine if the text is emphasized text, a pull quote, or a header.

Using sentence case in page titles, headers and main menu link titles:

• May not be as noticeable at a glance
• May appear unintentional
• Support: Typography for Glanceable Reading: Bigger is Better (Nielsen/Norman Group)

Examples:

• Sentence case: Our research
• Title case: Our Research
• Sentence case: Who we are
• Title case: Who We Are

IMPORTANT: The key is to have a consistent presentation of case/capitalization across your site. So, whatever case style you choose, it should be consistent sitewide.

Consistency — Headers, Sections and Buttons

The KU CMS Sunflower provides a lot of options for headers, buttons, dividers, etc. You should use the sections strategically to create a consistent user experience across your website. Consistency in your choices will help determine how quickly your users understand how your site works.

• Choose a header for your home page that makes that page stand out. Your home page is the most important page on your site and it should appear to be special.
• If your site has landing pages you could choose another type of header for those pages.
• Choose another header and use it consistently for interior pages.
  • Avoid using a splashy header for all interior pages. You should establish an order of hierarchy between your pages.
• Choose one button style for your site, unless you have a strategic reason.
• Choose one divider style for your site.
• Choose consistent CTA sections.
• Use either Body 21 or Body 1, if you are using a sidebar.
• Create a design system of sections for your site.

Consistency — Links in Menus, Buttons and Sections

• We strongly recommend using title case in menus, buttons and sections that contain links.
• Title case capitalizes the first letter of all words except prepositions, articles and conjunctions
• No matter what case you use, it should be consistent on a given page — and when possible across the site.

Title Case

Capitalize:

• Nouns
• Pronouns
• Verbs
• Adjectives
• Adverbs

Do not capitalize:

• Prepositions (e.g., in, at, to, of, on, etc.)
• Articles (e.g., an, a, the, etc.)
• Conjunctions (e.g., for, nor, but, or, yet, so, etc.)

Consistency — Link and Page Titles, URL and H1 Headers

Continuity and consistency for users are among the guiding principles of user experience (UX) web best practices.

Avoid making users work to understand if they have arrived at their intended destination. It is important that a page’s link titles, page title, URL, and H1 header are closely connected.

A user should be able to select a link title and then find a page title, URL, and H1 header that all reassure them of a successful navigation choice. Page titles and H1 headers can be more detailed than the link title, but they should include the same words in the link title to signal success.

Additionally, the H1 header is critical to your site’s searchability/SEO. It’s important that headers – especially H1 and H2 – are written as concisely as possible and using the “terms” your users are likely to use when searching for that content. See Headers for more info, including guidelines and best practices. 

Examples

Less Effective User Journey

• Link title: About
• Page title: About [Organization name]
• URL: /about
• H1 Header: We Are Here to Serve Our Customers

More Effective User Journey

• Link title: About
• Page title: About [Organization name]
• URL: /about
• H1 Header: 1) About; 2) About Us; 3) About [Organization name]

Headers — Effective Writing

• Headers should be simple and concise. Use as few words as possible.
• Headers should be written for optimized search results:
  • Use the keywords that users are likely to search for (e.g., Google, Yahoo).
• Write headers and sub-headers so they are easily scanned with the most important words first
• Use plain language
• Avoid jargon and acronyms
• Full sentences (e.g., taglines) should not be used as headers in most cases.
• Do not use taglines for headers except on marketing-style pages and only if the tagline is part of a section designed to deliver users to the content.
  • If a tagline is used as a header it is likely to deliver poor search results.

Hosting — Content You Do Not Control

As a general rule, it is important to avoid hosting content (e.g., documents/pdfs, web copy) on your website that you do not own and control (i.e., have the authority to change). Instead, you should point to an external destination where the information is hosted by the content owner.

The Danger of Hosting Someone Else’s Content

• If the content owner makes changes to the document/web copy, the information on your site will become inaccurate and you will have no way of knowing that the source information changed.
• Hosting out-of-date information on your site can damage your user’s perception of your site’s credibility and trustworthiness.
• Documents - If you host someone else’s document, you take on the responsible of ensuring the document you host on your KU CMS site is accessible. Meaning you are likely to have to make changes to documents you do not control during the accessibility remediation process.

Solutions

• In most cases, the content owner is already making the information available online. You can simply provide a link to their document/webpage. That way when the content owner makes changes, you connect your users to the current information.
• If the content is not currently posted online, reach out directly and ask the content owner to post it so you can provide a link.

Quoting vs. Hosting Content

In some cases, it may be helpful to quote a small amount of specific information rather than asking a user to leave and go to a different website. If you must do so, remember the following:

• Be sure to properly attribute the information to the content owner
• Give yourself a reminder to check the accuracy of the quoted information frequently enough to avoid issues

Hosting — Archival/Historical Content

In most cases, we recommend avoiding hosting documents and historical web content that is/are more than ~2 years old. Exceptions include special news articles and websites with a primary purpose of providing archival and/or historical information. Documents should be removed or converted to accessible web content whenever possible.

• For accessibility and usability, content from PDFs and other documents should be moved to webpages whenever possible.
• With the exception of special news articles, we do not recommend hosting information that is more than ~2 years old on your site.
• Archival and historical documents/content do not add value for most users
• Archival and historical documents/content can clutter the user experience and prevent users from finding salient information
• Archival and historical documents/content can appear to be outdated content and compromise the credibility and trustworthiness of your site for users.
• Archival and historical documents/content on KU CMS sites must be accessible. Remediating PDFs and other documents can be difficult and time consuming. The burden of remediating large numbers of archival/historical documents is extensive.
• If you offer documents as a resource, consider reducing your remediation burden by limited the documents to a select handful of accessible documents and offering users the option of contacting you for additional documents via email.

Menu – Pages Not in the Site Menu

The majority of your pages should be findable in the site menu system. Without question all pages that contain important information for your primary audiences belong in the menu. Unless you have a strategic reason not to, put the pages on your site into the menu system.

Why? Users seek information in different ways. Some use the site search. Some start on the homepage and move organically from there. Some use the site menu to find what they are looking for. You want to make it easy on users to find what they are looking for regardless of how they prefer to use the site. If your pages are not in the menu, you remove a primary method of information seeking and increase the likelihood those pages will not be found by some users.

There are some instances where pages can/should remain outside of the site menu system.

Examples of Pages That Can Site Outside the Menu:

• End of the trail pages - These pages typically contain information about a single topic, but have too much information to be included on a primary page.
• Temporary One-off pages - Special pages for temporary topics
• Special landing pages - These pages are often marketing pages designed to deliver users from paid advertising to a special landing page rather than start users on the site homepage. 

Menu — Contents

• If the pages are on the site, the menu contains: About, Academics, Admissions, People, Research

See Menu/Navigation for recommendation specifics.

PDF Forms

We strongly recommend converting PDF forms to accessible and user-friendly webforms whenever possible. PDF-based forms are often difficult to remediate due to the complexity and formatting of traditional forms. As a result, the burden of maintaining accessible PDF forms overtime can be significant.

See Webforms to learn about the supported webform options at KU.

Person Profile — Use Jayhawk Placeholder if No Profile Image Available

Both the Person Profile and Body 13 - Profile Directory are designed to work with an image present.

If there is no profile image available for a profile on your site, we recommend using this Jayhawk Placeholder Image instead of leaving it blank. 

Tables — Use Sunflower Table Styles

We strongly recommend using one of the following table styles on all tables.

• Basic Table
• Bordered Table
• Fog Header Table
• Lake Header Table
• Striped Table

Submit Your First Site for Review Before Submitting Additional Sites

Many CMS site administrators have more than one site to migrate/develop.

We strongly recommend developing one of your sites first and then submitting that site for review before you begin work on further sites. This allows you to go through the review process and leverage the feedback you receive as you develop additional sites.

It is much easier to carry any lessons learned forward as you create new pages than it is do go back and correct issues across an entire site that has already been created.

If you have already started developing multiple sites, that is totally fine. We still recommend you submit one of your sites ahead of the others and then translate the feedback you receive to the other properties before submitting them for review.

Improper Use of Headers

Headers and sub-headers (a.k.a., headlines and sub-headlines, headings and sub-headings) are a critical element of website design, organization and writing that is too often overlooked. Users should be able to find what they are looking for on your website by reading your headers and sub-headers only. Headers have a direct impact on the usability and searchability of your site.

Common Header-related Errors:

• Headers are not concise/simple
• Headers do not reflect the words users would use to search for that information
• Header classes have been applied to statements/long sentences that are not actually headers in the page organization scheme
• Header classes are used out of order (i.e., H1, H2, H3…)
• Headers are used for aesthetics (e.g., font-size, bold) instead of organization and searchability
• Header classes have been unnecessarily bolded

See Headers for more information, including guidelines and best practices.

Stock Photography and Images Without Value for Users

When selecting photos for your site, it is important to avoid two kinds of images:

1. Stock photography (i.e, stock photos from non-KU sources)
2. Images that do not add emotional or contextual value in direct support of the information on a page

These kinds of images can damage the user experience because they do not provide clear and meaningful value to your users – and it puts a literal barrier between your users and the information they are seeking.

This is especially important in header sections and tops of pages. It is far better to begin with text information that adds value for users than to force them to scroll past an image that provides only aesthetic value.

Images you do not have clear and verifiable rights to use are not permitted on KU CMS websites.