Sometimes good intentions make for not-so-good web content. Here are some familiar offenders:

• “Click Here”
  Seems helpful. Isn’t. Tell people where the link goes instead: “View the academic calendar.” Bonus: screen reader users will thank you.
• A PDF of a flyer
  Looks great on your office bulletin board. Maybe not so much on a phone or screen reader. If the information belongs on the web, consider making it a webpage instead.
• ALL CAPS HEADINGS
  VERY IMPORTANT LOOKING. NOT NECESSARILY VERY READABLE. Use clear, descriptive headings and let the website handle how they look.
• “Welcome to the Department of…”
  Your visitor already knows where they are. Instead, use that valuable space to tell them what they can do, find or learn there.
• Opening every link in a new window
  You might think you’re helping visitors keep their place. Instead, you’re taking control of their browser and potentially confusing them. Let visitors decide when they want a new tab.
• “For more information…”
  More information about what? Links should make sense on their own. Try “Learn about financial aid options” instead.
• Putting everything on the homepage
  If everything is important, nothing is important. Your homepage should help visitors find their next step—not contain every step.
• Making something bold, bigger or a different color instead of using a heading
  It may look like a heading, but that doesn’t make it one. Use actual heading styles so the structure of your page works for everyone.
• Uploading another copy “just in case”
  Now there are two versions of the same information—and eventually they’ll disagree. Whenever possible, maintain one authoritative source and link to it.
• Keeping an old page because “someone might still need it”
  Maybe. But outdated content can be worse than no content at all. If a page no longer serves a clear purpose, update it, archive it or let it retire with dignity.
• “Read More”
  Read more about what? When a page has several “Read More” links, they’re especially unhelpful to people navigating by links. Try something descriptive like “Explore undergraduate research opportunities.”
• Underlining text for emphasis
  On the web, underlined text looks like a link. If it isn’t clickable, visitors may spend a few seconds wondering why it’s broken. Use emphasis styles for emphasis and save underlines for links.
• Using a table to make things line up
  Everything is beautifully arranged in rows and columns—until someone views it on a phone or uses a screen reader. Use tables for actual tabular data, not page layout.
• “See below”
  Below where? On a phone, “below” might be several screens away, and a screen reader user may navigate the page differently. Refer to the section or heading by name instead.
• Putting important information in an image
  That graphic may look fantastic, but search engines, screen readers and people zooming on a phone may have a harder time getting the information from it. Put essential information in actual webpage text.
• Using headings because of how they look
  H2 is too big, so you choose H4. Problem solved—visually. Structurally, not so much. Choose headings based on the organization of the content, not their appearance.
• “Coming Soon”
  Coming when? A “Coming Soon” page created three years ago isn’t building much anticipation. Publish when you have useful information to share—or include an actual timeframe.
• Putting an email address everywhere
  Sometimes contacting someone really is the next step. But if 50 people are likely to ask the same question, the answer probably belongs on the website first.
• Adding “Important!” to make something important
  IMPORTANT! PLEASE NOTE! ATTENTION! If everything is urgent, visitors quickly learn to ignore all of it. Good placement, clear headings and concise writing do a better job of establishing priority.
• Writing for the organizational chart
  Visitors don’t necessarily know which office, division or committee owns the thing they need. Organize and describe content around their task, not your internal structure.
• Listing every possible audience
  “Information for students, faculty, staff, parents, alumni, visitors and community members…” Congratulations—you’ve described almost everyone. Focus instead on what people came to the page to accomplish.
• Using “FAQs” to avoid organizing the content
  Sometimes FAQs are useful. Sometimes they’re just a very long page where every heading is a question. If the information has a natural structure, give it one.
• Repeating the same information on several pages
  It feels convenient—until the tuition amount, deadline, phone number or policy changes and someone has to remember everywhere it was copied. Write it once and link to it.
• Putting the date in an image
  Nothing says “quick update” like finding the original Photoshop file because the event moved from Tuesday to Wednesday. Keep details that may change as editable webpage text.
• Using the homepage as a filing cabinet
  That link might be useful to someone, but that doesn’t mean it belongs in the main navigation or on the homepage. Design navigation around common visitor needs, not requests to “add our link somewhere.”
• Keeping content because “we’ve always had it”
  Longevity isn’t the same thing as usefulness. Every page should have an audience, a purpose and someone responsible for keeping it accurate.
• Writing like a university
  “The Office of Whatever endeavors to facilitate the provision of resources…” You’re allowed to say “We can help you find…” Clear, conversational language isn’t less professional. It’s more useful.

Editor Action: Find it. Fix it.
Open one page you manage and look for at least one of these offenders. Replace that “click here,” rethink that PDF, fix that heading, remove outdated information or give your introduction a purpose. Then, if you’re feeling ambitious, find another one.

Need help figuring out the better approach? Read “Creating Better Content for the UTC Website” for tips, how-tos and guidance.

The post Things That Seem Helpful but Aren’t appeared first on UTC Website Knowledge Base.

Creating a web page is easy. Creating one that people can quickly understand, navigate and use takes a little more thought.

When you create content for the UTC website, remember that most visitors arrive with a task in mind. They may be looking for a deadline, trying to apply for a program, finding a form, checking requirements or figuring out who to contact. Your job as a content editor is to help them get there as quickly as possible.

Here are some practices that make a big difference.

Start With What Your Visitor Needs

Before creating a page, ask a simple question:

What should someone be able to do after visiting this page?

Build the page around that answer. Important information and actions should appear early rather than being buried beneath introductions, history or organizational descriptions.

Instead of beginning with:

Welcome to the Department of…

Consider starting with what your audience came to find: programs, services, deadlines, requirements or next steps.

Write for Scanning, Not Reading

People rarely read a web page from beginning to end. They scan.

Make that easy by using:

• Short paragraphs
• Descriptive headings
• Bulleted lists when appropriate
• Clear links and calls to action
• Plain language
• The most important information first

A visitor should be able to glance at your headings and understand what the page contains.

Make Your Link Text Mean Something

Avoid links such as Click Here, Learn More or Read More when you can describe the destination instead.

Instead of:

To view the academic calendar, click here.

Use:

View the Academic Calendar.

Descriptive links are easier to scan, more accessible to people using assistive technology and give visitors confidence about where a link will take them.

Use Headings for Structure, Not Decoration

Headings organize information. They aren’t simply a way to make text bigger.

Your page title is the primary heading. Sections underneath it should use heading levels in a logical order. Don’t choose a heading level because you like its size or appearance—the website’s design should handle that for you.

Good structure benefits everyone and is especially important for visitors using screen readers.

Keep Important Information on the Web

Have a flyer? A Word document? A PDF?

Before uploading it, ask whether the information would work better as a web page.

Web content is generally easier to use on phones, easier to search, easier to update and easier to make accessible. Documents still have their place—especially when something needs to be downloaded, printed or retained—but they shouldn’t automatically be the first choice.

If the information is meant to be read online, make it web content whenever possible.

Don’t Make Visitors Decode University Language

Higher education loves acronyms, department names and terminology. Your visitors may not.

Write for the person who knows the least about UTC, not the person sitting in the office next to you.

Spell out unfamiliar acronyms the first time you use them, explain specialized terminology when necessary and use the words your audience is likely to search for.

Make Calls to Action Obvious

If there is something you want visitors to do, tell them.

Apply for Admission.
Request Information.
Schedule an Appointment.
View Degree Requirements.
Contact the Department.

Don’t make visitors read three paragraphs to discover their next step.

Remember Accessibility Is Part of Content Creation

Accessibility isn’t something that gets added to a page later. Editors contribute to accessibility every time they create content.

That means:

• Adding alternative text that communicates the purpose of meaningful images
• Using headings correctly
• Writing descriptive links
• Avoiding instructions that depend only on color or visual position
• Creating meaningful text instead of placing important information inside images
• Using tables for data, not page layout
• Making documents accessible when a document really is necessary

Accessible content usually turns out to be better content for everyone.

Don’t Duplicate Content Unless You Have To

Copying the same information onto several pages may seem convenient—until something changes.

Then someone has to remember everywhere it was copied.

Whenever possible, maintain information in one authoritative location and link to it from other pages. This reduces outdated or contradictory information and makes maintaining the website much easier.

Review Before You Publish—and After

Publishing shouldn’t be the last time you look at a page.

Before publishing, check:

Is this accurate? Is it current? Is it understandable? Is it accessible? Is it still necessary?

And periodically ask the most dangerous question of all:

Does this page still need to exist?

Good web content isn’t measured by how many pages we create. Sometimes the best content improvement is updating, combining or removing something that’s already there.

Your Editor Action

Pick one page you manage and look at it as though you’ve never seen it before.

Can you tell what the page is about in five seconds? Can you quickly find the most important information? Is the next action obvious?

If not, you already know where to start.

The post Creating Better Content for the UTC Website appeared first on UTC Website Knowledge Base.

How the UTC Calendar Integrates with MocSync

One of the key features of the UTC Events Calendar is its ability to display student organization events that originate in MocSync. If your website needs to display events from a student organization, the preferred approach is to pull those events from MocSync into the UTC Calendar.

To set up this integration, the Web Team will need the name of the organization as it appears in MocSync. An RSS feed can then be configured to bring the organization’s events into the UTC Calendar, allowing them to be displayed through Localist widgets on your website.

For many groups, this means there is no need to become a UTC Calendar editor. If all of your events can be managed through MocSync, maintaining them in MocSync alone will automatically support both calendar visibility and website event displays.

For more information on MocSync, contact Hannah Turcotte, in the Center for Student Leadership, Engagement, and Community.

When You May Need UTC Calendar Editor Access

Some events may not originate in MocSync or may require direct management within the UTC Calendar. In those cases, you have two options:

• Request training to become a UTC Calendar editor. Editor access allows you to create and manage events directly within the UTC Calendar, though the training and onboarding process may take some time.
• Submit a request for assistance through the UTC Service Portal at:
  https://utc.teamdynamix.com/TDClient/2717/Portal/Requests/Service/53945/General-Inquiry

The service request option is often the quickest solution for occasional event submissions or calendar-related questions.

Creating and Embedding a Localist Calendar Widget

Once your events are available in the UTC Calendar, you can display them on your Drupal website using a Localist widget. Widgets allow you to surface upcoming events from specific calendars, departments, or organizations directly within your site.

Step-by-step instructions for building and embedding a Localist Events widget are available only to Super Users in the Web Knowledge Base here.

By combining MocSync, the UTC Events Calendar, and Localist widgets, departments and organizations can maintain a single source of event information while ensuring events are visible across both the university calendar and their own websites.

The post Understanding the UTC Events Calendar and Localist Widgets appeared first on UTC Website Knowledge Base.

PDFs that do not meet the requirements below may not be uploaded to the website.
Note: The UTC website only allows PDF files, not Word, PowerPoint or other document types.
Creating and sharing accessible, up-to-date PDFs helps ensure that everyone can access your information easily while keeping our website fast, organized, and compliant with federal standards. Please review the following questions before submitting your documents for upload.

1. Can your PDF(s) be a webpage instead?

In many cases, turning your document into a webpage is a better choice. Webpages are easier to update, automatically meet most accessibility standards, and don’t take up as much storage space as PDFs. They also work better on phones and tablets.
If your content could be displayed as a webpage rather than a downloadable file, submit a webpage request here and our team will be happy to help you make the conversion.

2. Is your document meant for public use?

Before uploading, make sure your PDF is meant to be shared publicly. Only materials that inform or serve the general public should be published on departmental websites.
Examples of documents appropriate for public upload:

• Public reports, policies, or official statements
• Public-facing forms, guides, or instructions
• Research summaries or outreach materials
• Student and community resources

Documents that should not be uploaded to the public site:

• Course syllabi or classroom materials
• Event flyers and announcements (Please use the UTC events calendar service, which will ensure that past events are not displayed on the website.)
• Faculty or staff CVs/resumes (Digital Measures is the best solution for faculty biographies and can be displayed on the website by request.)
• Internal memos, drafts, or meeting notes
• Documents intended for limited audiences (e.g., committees, student organizations, classroom documents, departmental documents, etc.)

If a document serves an internal purpose, please share it through internal systems such as SharePoint, Canvas, or email instead of a public webpage.

3. Does your PDF(s) meet accessibility standards?

All PDFs published on the UTC website must meet federal accessibility requirements. Under the U.S. Department of Justice (DOJ) and ADA Title II, electronic documents—such as PDFs—must comply with WCAG 2.1 Level AA standards.

• Learn more about the DOJ Accessibility Mandate
• View our guide on creating accessible PDFs

Accessibility ensures everyone—including people using assistive technology—can read and interact with your content. Documents that do not meet these standards may be delayed or returned for revision.

4. Does this new PDF(s) replace old or outdated PDF(s)?

To keep content relevant and avoid confusion, please include links to any older PDFs that your new document replaces. Google indexes and displays PDFs in search results, which means outdated versions may still appear even after you’ve uploaded an update. Removing old files helps users find the most accurate, up-to-date information and keeps our storage costs low.

5. Is your PDF(s) optimized to reduce the file size?

Optimized PDFs load faster, save storage space, and are easier for everyone to access—especially on mobile devices. Large, uncompressed files can slow down your page, frustrate users, and hurt search rankings. By compressing images, removing hidden data, and tagging text for screen readers, you make your PDF faster, lighter, and more inclusive.

• Learn how to optimize your PDF here.

The post Departmental PDF Submission Guidelines appeared first on UTC Website Knowledge Base.

Go here to view the FontAwesome library of icons.

See the table below for the code to implement UTC Customized icons.

For details on how to implement icons, Faculty and Staff can watch Video 8 in our Canvas training module. You must be invited as a “student” to have access. Reach out to us at webhelp@utc.edu for access.

The post FontAwesome and Customized UTC Icons appeared first on UTC Website Knowledge Base.

The downside is that many infographics leave people out.

When an infographic is not accessible, it can become invisible—or confusing—to users with disabilities. On the web, that’s a real problem, especially for public institutions and organizations that serve everyone.

Below is a clear look at the main accessibility concerns with infographics, why they matter, and how to fix them.

The Core Problem: Images Don’t Talk

An infographic is usually just one big image. To a screen reader (software that reads web content out loud), that image is silent unless you give it words.

Think of it like hanging a detailed poster on a wall in a dark room. If no one turns on the lights or explains what’s there, some people simply can’t access the information.

That’s why accessibility always starts with text alternatives.

Solutions to consider

1) Build the infographic as a web page first (not a single image)

If the “infographic” is really information (steps, stats, comparisons, timelines), the most accessible way to publish it is as real web content—headings, short sections, lists, and simple charts—then use visuals as support.

Why this is better

• Screen readers can read it naturally (because it’s text, not a picture).
• People can zoom text without it getting blurry.
• It works better on mobile.
• Search engines can understand it.
• You can still make it look like an infographic using UTC components and icons (cards, callouts, stat blocks, accordions, tabs, icon lists, timelines, etc.).

Real-life example
Instead of a “one-poster infographic,” think of a museum exhibit:

• Each panel has a headline + a short explanation.
• Visuals are there, but the story is still readable even if you ignore the images.

What this looks like in practice

• Convert each section of the infographic into:
  • A clear heading
  • 1–3 short sentences
  • A list or table if needed
  • A small chart (optional) with labels
• Use UTC’s existing components to keep it branded and “designed,” not plain.

2) Keep the image version as a supporting visual (optional)

If you still want the “poster-style” image:

• Include it below the web version, not instead of it.
• Treat it like an illustration, not the only way to get the info.

3) If you do use an infographic image, write useful alt text

Alt text should explain the main point, not just “infographic.”

• Bad: “Infographic about enrollment”
• Better: “Enrollment rose steadily from 2018 to 2024, with the biggest increase in online programs.”

For complex visuals, add a text version right below it.

4) Don’t use color as the only way to communicate meaning

If the chart relies on “red vs green” or “light blue vs dark blue,” some users won’t be able to tell the difference.

Fixes:

• Add labels directly on the chart
• Use patterns or icons
• Make sure contrast is strong

5) Avoid embedding lots of text inside the image

Text inside images:

• can’t be resized well,
• gets blurry on mobile,
• is often missed by assistive tech.

If it’s important, it should be real text on the page.

6) Put the data in text form too

If the infographic is based on numbers:

• add a small table,
• or a bullet list of key takeaways.

This helps everyone skim and helps screen readers.

Quick “UTC-ready” checklist

• Web page version is the primary content
• Use UTC components + icons to keep it visual
• Optional image version has alt text + text version
• No color-only meaning
• Data exists in text/table form
• Works well on mobile and keyboard

The post Infographics on the Web: Accessibility Concerns You Can’t Ignore appeared first on UTC Website Knowledge Base.

1. Start with a clean table (before it becomes a PDF)

If you can, fix the table in Word, Google Docs, Excel, or InDesign first. PDFs inherit problems from their source. For more video resources to these applications, please go here.

What to do

1. Use a real table tool (Insert → Table)
2. No tabs or spaces to “fake” columns
3. One idea per cell

Why this matters

Screen readers only recognize real tables. Fake tables turn into unreadable text soup.

If you don’t have access to the original document, please scroll down to watch this video on using Adobe Acrobat to make your tables accessible.

2. Use proper header rows (this is the big one)

Every table needs column headers (and sometimes row headers).

What to do

• Identify the top row as headers
• If the first column labels rows, mark that too

Why this matters

A screen reader says things like:

“Enrollment, 2024, 1,245”

Without headers, it just says:

“1,245”

No context = meaningless data.

3. Keep the table simple

Simple tables are accessible tables.

Avoid

• Merged cells
• Split cells
• Tables inside tables
• Diagonal headers

Good rule of thumb

If you have to explain the layout out loud, it’s probably too complex.

What to do

Screen readers read tables line by line, not visually.

4. Export to PDF correctly

When saving or exporting to PDF, you must keep the structure.

In Word

• File → Save As → PDF
• Make sure “Document structure tags for accessibility” is checked

In InDesign

• Export → Adobe PDF (Interactive or Print)
• Check “Create Tagged PDF”
• Make sure table headers are set in InDesign

Why this matters

Tags are the hidden map that tells assistive tech how content is organized.

6. Run the Accessibility Checker (but don’t trust it blindly)

Tools → Accessibility → Full Check

It will:

• Catch missing headers
• Flag broken structure

But the checker is like spellcheck—it helps, but you still need human judgment.

7. Add a summary (optional but helpful)

If the table is dense or data-heavy, add a short sentence before the table explaining it.

Example

“The table below shows student enrollment by year and department.”

Why this helps

Screen reader users get context before diving into raw data.

Making Tables Accessible in a PDF in Acrobat

The post No More Data Soup: How to Fix PDF Tables appeared first on UTC Website Knowledge Base.

Web pages

• Info and Relationships
  Information and content relationships implied by formatting are communicated in text or in a way that works with assistive technology.
• Meaningful Sequence
  The reading order of content is meaningful, no matter how a user accesses or consumes it.
• Sensory Characteristics
  Instructions rely on more than one sense.
• Use of Color
  Color is not the only way used to distinguish an element, convey meaning, indicate an action, or prompt a response.
• Page Title
  Page titles clearly describe the page topic or page purpose.
• Link Purpose (In Context)
  The purpose of each link can be determined from the link text alone or from the link text and its related context.
• Labels or Instructions
  A persistent visible label and / or instructions are provided for elements that require user input.
• Captions (Live)
  Synchronized captions are provided for live videos containing audio.
• Audio Description (Pre-recorded)
  If there is important visual content in a video that is not presented in the accompanying audio, an audio description is provided.
• Contrast (Minimum)
  The contrast ratio between regular-sized, non-decorative text and its background is at least 4.5:1.
• Non-Text Contrast
  The contrast ratio between non-text elements (including any states) and their background is at least 3:1.
• Text Spacing
  Text spacing can be overridden to improve the reading experience.
• Content on Hover Focus
  When additional content is presented on hover or on focus, the new content is persistent and dismissable.
• Multiple Ways
  There is more than one way to reach each page.
• Headings and Labels
  Headings and labels are clear and descriptive.
• Dragging Movements
  If any part of a website requires a dragging movement, an alternative means of dragging, such as tapping or clicking, is provided.
• Target Size (Minimum) 
  The size of a target is at least 24 by 24 CSS pixels (with exceptions).
• Consistent Navigation
  Navigational elements are consistently displayed, including their location and the order of their content.
• Error Suggestion
  Users receive helpful / specific suggestions when they make errors.
• Error Prevention (Legal, Financial, Data)
  When users enter financial or legal data, submissions are reversible, and data is checked and confirmed before submission is finalized.
• Status Messages
  Status messages can be presented to the user by assistive technology without receiving focus.

Images, video and audio elements

• Images of Text
  Aside from a few specific exceptions, there are no images of text.
• Non-text Content
  Text alternatives are provided for non-text content such as images, videos, and audios.
• Audio-only and Video-only (Pre-recorded)
  A transcript is provided for audio-only content and a transcript or audio description is provided for video-only content.
• Captions (Pre-recorded)
  Captions are provided for video with audio.
• Audio Description or Media Alternative (Pre-recorded)
  A transcript and / or audio descriptions are provided for video with audio.
• Audio Control
  A mechanism is provided to control audio that plays on page automatically for more than three seconds.
• Pause, Stop, Hide
  User controls are provided for moving or dynamically changing content.
• Three Flashes or Below
  No content flashes more than three times per second, or the flash is below flash thresholds.

For more on video formatting and accessibility, please read our article here.

For more on creating accessible PDFs, please read our article here.

The post WCAG 2.1 AA Checklist for Content Editors appeared first on UTC Website Knowledge Base.

Where should departments store and share documents moving forward?

Why the main website isn’t the answer

While our main website does allow PDF uploads (up to 6MB), it is not designed to be a document storage solution.

• It only supports PDF files
• It does not support Word, Excel, PowerPoint, or other file types
• It is not built for organizing, updating, or managing large sets of documents

(For more details on uploading PDFs to the website, see our separate PDF upload article.)

So if your office needs to store and share multiple documents—or file types beyond PDFs—you’ll need a different approach.

Three practical options

Option 1: Share documents by request

If your documents are requested infrequently, you can ask users to contact your office directly to receive them.

This works, but it often leads to:

• repeated email requests
• manual file sending
• workflow congestion for your staff

For anything with regular traffic, this approach doesn’t scale well.

Option 2: Upload documents to Canvas (student-focused files)

If your documents are primarily for students, Canvas is often the best option.

Canvas is designed for instructional and student-facing materials and works well for:

• Course-related documents
• Forms or resources tied to classes or programs
• Files students need to access regularly

Benefits of using Canvas:

• Supports multiple file types (PDF, Word, PowerPoint, Excel, etc.)
• Content is organized by course or program
• Access is limited to enrolled students
• No public-facing accessibility concerns tied to the main website

Canvas should be used only for materials intended for students—not for public-facing documents.

NOTE: All documents uploaded to Canvas are still subject to the DOJ’s accesibility mandate.

Option 3: Use a SharePoint site

A dedicated SharePoint site gives your office a controlled, flexible place to store and share documents.

With a SharePoint site, you can:

• Upload Word, Excel, PowerPoint, PDFs, and more
• Organize files into folders
• Link directly to documents from your main website
• Control who can and cannot access files

Important things to know

• SharePoint sites are limited to people with university credentials (UTC ID)
• Users may be prompted to log in before viewing documents
• External users can be given access, but only:
  • to specific files
  • on a case-by-case basis
  • provided via email links

Step-by-Step: Creating and Using a SharePoint Document Site

Step 1: Create the SharePoint site

1. Go to https://office.com
2. Sign in with your university account
3. Open Microsoft SharePoint
4. Click Create site
5. Choose a site type
   • Team site – best for collaboration
   • Communication site – best for read-only content, policies, and resources. Most campus-wide document sites should use a Communication site.
6. Select Communication site
7. Choose a layout (Blank is fine)
8. Click Next
9. Enter:
   • Site name (clear and official)
   • Description (optional)
10. Click Finish

Step 2: Add Documents to the site home page

Adding Documents to the landing page makes files easy to find.

1. Click Edit (top right)
2. Add the Documents widget
   • Hover where you want the documents to appear
   • Click the + icon
   • Select Document Library (sometimes labeled “Documents”)
   • Choose the Documents library
   • Click Add
3. Configure the display (recommended)
   • View: All Documents or a custom view
   • Show toolbar: On
   • Folder navigation: On
4. Rename the section header to something clear, such as:
   • Shared Documents
   • Forms and Files
   • [Dept. Name] Resources
5. Click Publish or Republish when finished.

Step 3: Upload documents

1. Go to Documents
2. Click Upload
3. Choose Files or Folder
4. Select files from your computer
5. Click Open
6. Files upload immediately and appear on the home page if the library is embedded there.

Step 4: Make documents visible to everyone with university credentials

If documents should be available campus-wide:

1. In Documents, click the gear icon
2. Select Library settings
3. Click Permissions for this document library
4. Click Grant Permissions
5. Add:
   Everyone except external users
6. Set permission to Read
7. Click Share
   • All files in the library now inherit campus-wide access.
8. Confirm access
   • Open a private/incognito browser
   • Sign in with a different university account
   • Open a document
   • Confirm no access request appears

Step 5 (optional): Share with external users

When needed, you can share individual files with external people.

1. Open Documents
2. Hover over the file
3. Click Share
4. Open Link settings
5. Choose Specific people
6. Set permission to View
7. Enter the external email address
8. Click Send

The recipient will receive a secure email link. Access can be removed at any time.

Final takeaway

If your office needs a reliable replacement for Google Drive—especially for multiple file types and campus-wide access—SharePoint is the right tool.

Use the website for content, and SharePoint for documents. Add the needed links to your website with accompanying copy about University restrictions and workarounds.

The post Wait, what? Are we getting rid of Google Drive? appeared first on UTC Website Knowledge Base.

WAVE (Web Accessibility Evaluation Tool) is a browser-based accessibility checker developed by WebAIM that helps you visually identify accessibility issues and features directly on any web page. It overlays icons and indicators on a page to show where potential accessibility concerns exist, offering context and guidance for each item 

The post WAVE Accessibly Extension  appeared first on UTC Website Knowledge Base.