Frequently Asked Questions

The Web Platform Services team (the developers and maintainers of the Open Berkeley platform) is available to provide support for all Open Berkeley sites. Please email web-platform@berkeley.edu with any/all questions.

No, not unless you are using one of our built-in widget types. (See below for a list.) Content and widgets generated by third-party services may cause security, accessibility, privacy, or maintenance problems if embedded directly.

Embedding a widget that has not been properly tested with the Open Berkeley platform could have any of the following issues:

• Improper display (especially if it loads an application/product that requires some kind of authentication)
• Insecure code that will pose security risks for your site visitors
• Functionality that is not accessible to people with disabilities (in violation of the UC accessibility policy)
• Collection or exposure of visitor data (in violation of our Privacy Statement and the Campus Online Activities Policy)

In order to prevent these issues, tags used to embed external content, including but not limited to iframe tags, object and embed tags, and script tags, are stripped from your page content when saving.

Several of our widget options allow for embedding of outside content, such as charts, videos, and bConnected / Google products:

• Berkeley Events calendar
• Class Listing
• Google and bConnected
• Data visualization
• Twitter feed
• Video

If the information you need to display is from an external site or application and is not included in the above list, you can simply link to it instead of embedding it on your site. Any content you control, regardless of where it is hosted, should comply with all applicable campus policies including those linked above.

If you have any questions, please email web-platform@berkeley.edu.

You are welcome to sit in on a training session, stop by office hours, or complete our Sign Up form to learn more.

Please visit the Open Berkeley Managed Website Platform page in the IT Service catalog.

Anyone with the Site Builder role can add new users and modify roles on their Open Berkeley site. New users will need to log in to the site first before a role can be added. Please see Add New Users and Modify Roles.

We don't typically recommend opening links in new tabs. The World Wide Web Consortium (W3C) does not recommend this practice, as it takes the control out of the user's hands (opening a new tab without the user's consent).

It's also an accessibility best practice to not have links open automatically in a new tab/window, as links opening automatically in new tabs/windows can cause confusion for screen reader users, as well as users with certain cognitive disabilities. Visitors without disabilities can always choose to open links in a new browser window or tab if they desire (e.g., right-click the link and select "Open Link in New Tab" or "Open Link in New Window").

The first action you should take is to flush cache on your site - see the Site Builders Guide. You or someone else with the Site Builder role will have to do this. If flushing caches does not fix the issue, please email web-platform@berkeley.edu with the following information:

• Which site you are working on
• An explanation of the problem you are seeing (include screenshots if possible, and include URLs to specific pages on your site)
• If applicable, provide any notes about which actions you were taking on your site before this issue started occurring 

Yes, it's true that the UC has an accessibility policy.

The Open Berkeley platform is built to support accessibility! This means that most of "heavy lifting" has been taken care of in regards to the overall accessibility of any standard Open Berkeley website.

However, as content creators on your site, there are additional actions you can take to ensure that your content is accessible as possible to people with disabilities. See Accessibility for more information.

Yes, the test site is available for use after your site launches (once your site is live, all "real" edits need to be made on the live site). However, the test site is meant only to be used as a "sandbox" (a place to experiment) once your site is live. Once you try something out on test, you will need to re-create your finalized changes on your live site.

See the details outlined in Site Launch. The Web Platform Services team will need at least two weeks' notice for a proposed go-live.

Once you have reviewed the Site Launch details (linked above), email web-platform@berkeley.edu with the following information:

• Which site you would like to launch
• The name of the appropriate "Resource Proprietor" for your site
• When you would like to launch

Open Berkeley sites support the campus Berkeley Brand standards. The Berkeley wordmark, site name font, and Cal favicon (the icon displayed in the browser's tab bar) are part of the Berkeley Brand. See our documentation on Berkeley Brand theme options for information on how to configure the display of your site's header and footer. Also we encourage you to reach out to the Brand team at brand@berkeley.edu to see if they can consult with you or your team on understanding campus branding guidelines.

Although the Berkeley Brand does not allow custom logos in the header, you have the option to place your own logo in the footer, or on your home page or landing page for a particular section. You can create a reusable widget that would allow you to place the same logo image on multiple pages.

Upon request, the Web Platform Services team can put a page, or multiple pages, on your site behind CalNet authentication. This means that when site visitors go to these pages, they will be brought to a CalNet authentication screen, where they can log in with their CalNet ID and passphrase. Please email web-platform@berkeley.edu with the page, or pages, that you'd like to be placed behind CalNet authentication.

There are some caveats with this process:

• When a page is placed behind CalNet authentication, this means that all Employees, Faculty, Students, and HCM Affiliates (as defined by CAS Affiliations) can log in and view the page with their CalNet credentials.
• When anyone logs in to your site to view the page(s) behind CalNet authentication, their name will be added to your list of User Accounts (they will have no role assigned to them), which will lengthen the list. There are filtering/searching options on the User Accounts list that will make it easier to parse the list.
• Any attachments (uploaded PDFs, Word documents, etc.) that are added to page(s) behind CalNet authentication will still be available publicly (although will be difficult to find). If you need to ensure that all attachments are also only accessible via CalNet authentication, then we recommend putting those attachments on bDrive or Box instead, and linking to them from your pages.
• Authentication is based on the URL of the page. If the URL changes, the page may no longer be behind CalNet authentication.
• Even if the page is behind authentication, any data on the page still needs to fall into the Protection Level 1 category (i.e., no sensitive data is allowed). Please note that according to policy, "information intended for release only on a need-to-know basis" is considered Protection Level 2.

If you have content on your site that needs to be restricted to a certain set of people, we recommend using bDrive or Box to host and share that content (rather than working with our team to place the content behind CalNet authentication). 

When using the Mega Menu option, it's not possible to remove the automatic "Overview" link, as this link is important for accessibility and usability reasons.

When using the default “simple drop-down” menu option, site visitors can click the top-level menu item itself to get to the top-level content. With the optional Mega Menu, clicking the top-level item opens (activates) the mega menu, so we need another link (which we call "Overview") to take visitors to the top-level content for that menu item.

From a general user interaction perspective, site visitors generally expect to be able to get to some sort of top-level page (before moving down to other sub-level pages). Since the mega menu needs to open first (after the action of clicking with the mouse or tabbing with the keyboard), the "Overview" page serves as that top-level page. This is modeled after the menu structure on the Berkeley.edu gateway site.

Additionally, without the automatic addition of the "Overview" menu item, Site Builders could inadvertently build top-level pages that site visitors could never get to.

Lastly, the first item in the Mega Menu should not contain the same text as the item that opens the menu, since this can be problematic/confusing from an accessibility and usability perspective, and the "Overview" item prevents this from happening.