If your department manages a website with its own domain, be aware of a common deceptive scheme currently targeting domain owners at 杏吧原创. Specific domain registration companies are claiming that different domain names are about to expire and must be renewed immediately.

These may look legitimate, but they are often marketing solicitations disguised as renewal notices, with false information about the date of renewal. They frequently charge five times the average price of renewal, and may come via email or via surface mail. Paying the invoice will lead to your domain being transferred to the malevolent company. They then charge even more exploitative renewal rates.

The surface mail notices they send might look like this:

These companies often have several subsidiaries they use.

Always . A legitimate renewal notice should come from your current domain registrar electronically, or from an approved service provider.

You can often find information about the domain by and searching for your domain.

Common warning signs include:

• Unexpected renewal notices from companies you’ve never worked with.
• Claims that immediate payment is required to avoid losing your domain.
• Invoices that look like bills but contain fine print describing them as solicitations.
• Offers to renew a domain years before its actual expiration date.
• Requests to transfer your domain registration to a different company.
• A quoted price that is multiple times the market rate for a renewal.

If you receive a suspicious domain renewal notice, forward it to your website administrator or for verification.

Protect your website, your budget, and your peace of mind by staying alert to deceptive domain renewal practices.

The post Beware of deceptive domain renewal practices appeared first on cutheme docs.

For that reason, we ask that all support requests be submitted through Jira and that all communication related to those requests remain within the Jira ticket whenever possible.

Why Not Email or Teams Messages?

It may seem faster to send an email or Teams message directly to someone you know on our team, but in practice, this often has the opposite effect.

Individual mailboxes and chat conversations are not designed to manage support requests. Messages can be missed, buried among other work, delayed while someone is away, or become disconnected from the broader context of a request.

Most importantly, direct messages create an invisible queue. While the sender and recipient may be aware of a request, the rest of the team is not. If that individual is unavailable or working on higher-priority issues, the request may sit unnoticed when it could otherwise be reviewed and assigned through our normal support process.

What feels like a shortcut can actually result in slower resolution times.

Why Jira Works Better

Jira provides a single source of truth for every support request.

When a request is submitted through Jira:

• The work is tracked and prioritized appropriately.
• All team members can see the request and assist when needed.
• Decisions, updates, and technical details are captured in one place.
• Requesters have visibility into the status of their issue.
• Historical information is available for future reference.
• Work can continue even if a team member is unavailable.

This is particularly important because support is a team function, not an individual function. While you may have worked with a specific team member in the past, requests are often reviewed by multiple people and may be assigned based on expertise, workload, availability, and current priorities.

By using Jira, your request becomes visible to the entire team rather than relying on a single person’s inbox.

Keep the Conversation in the Ticket

Once a ticket has been created, we ask that all ongoing discussion remain within Jira comments.

This ensures that everyone involved has access to the same information and that a complete record of the request is maintained. If questions are asked or updates are provided through email or Teams, those details may not be visible to everyone working on the issue.

Support requests often involve multiple conversations, technical investigations, and decisions over time. Keeping those discussions within the ticket allows anyone working on the request to quickly understand its history without having to search through emails or chat messages.

There are some exceptions. In situations where files, screenshots, documents, or other materials cannot be attached directly to Jira, a Service Desk agent may ask you to provide them through another method. Even in those cases, the outcome of the discussion should be documented in the ticket so that the full history remains available.

Fair and Consistent Support

Using Jira also helps ensure that support requests are handled fairly and consistently.

Our team receives requests from across the university, many of which compete for the same resources. Jira allows us to review, prioritize, and assign work based on urgency, impact, complexity, and available capacity.

When requests are managed through email or private messages, it becomes much more difficult to track workload and ensure that all requests are receiving appropriate attention.

A centralized queue helps us provide consistent service to everyone rather than relying on who happened to contact a particular individual.

Helping Us Help You

Using Jira is not about creating extra steps or bureaucracy. It is about ensuring that requests are not lost, that work can be tracked effectively, and that our team can provide the highest level of service possible.

When all requests and communication remain within the ticketing system, we can respond more efficiently, collaborate more effectively, and provide better support for everyone.

The best way to ensure your request receives the attention it deserves is simple: submit it through Jira and keep the conversation in the ticket.

The post Why We Ask You to Use Jira for Support Requests appeared first on cutheme docs.

Over the last several releases, we have continued to improve accessibility validation within cutheme. Some of these changes have introduced new checks, while others have improved existing validation to better identify accessibility issues before content is published.

As a result, some content creators may notice additional warnings, publishing restrictions, or validation messages that were not previously visible. While these validations may feel new, the accessibility requirements behind them are not.

Summary of this post

This is an important topic so there is a lot to take in in this post. However, it can all be summarized as:

• Web accessibility is core to our efforts at 杏吧原创
• We have had accessibility checkers in cutheme for some time now
• We have now enhanced these so you might have to correct your content more frequently
• Accessibility is there to make the lives of everybody easier
• Review the checks described below so you can tell why you cannot publish/save a page

You can also learn more on our Web Accessibilty website.

Accessibility Requirements Are Not New

Accessibility has been a requirement for 杏吧原创 websites for well over a decade. These requirements did not originate with cutheme, WordPress, Gutenberg, or the Enterprise Solutions & Integrations team.

What has changed is our ability to identify accessibility issues earlier in the content creation process.

Historically, accessibility issues were often discovered during manual reviews, audits, or after content had already been published. As cutheme has evolved, we have introduced automated validation that helps identify many of these issues while content is being created.

Our goal is to provide content creators with immediate feedback, reduce the number of accessibility issues reaching production websites, and make it easier to create content that meets accessibility requirements from the start.

Why We Continue to Add Validation

Accessibility validation is an ongoing effort. As new opportunities are identified, additional checks may be introduced to help content creators catch issues before publication.

In some cases, this means introducing validation for requirements that were previously reviewed manually. In other cases, it means improving existing validation to catch scenarios that were not previously detected.

For example, heading hierarchy validation has existed within cutheme for some time. More recent improvements expanded this validation to properly evaluate the first heading used within page content, ensuring that the existing rule is applied more consistently.

The requirement itself has not changed. The validation has become more accurate.

These Requirements Will Remain

Accessibility requirements are not optional and exceptions will not be made to bypass accessibility validation.

While we understand that validation may occasionally require additional effort when creating content, these requirements exist to ensure that our websites remain accessible to all users, including those who rely on assistive technologies.

For that reason, accessibility-related validation rules will not be removed simply because they create additional work or require content to be updated.

Why Can’t Accessibility Issues Be Ignored?

Accessibility requirements are only effective when they are consistently followed.

While some issues are presented as warnings, others can prevent content from being published until they are corrected. This approach helps ensure that known accessibility barriers are addressed before content reaches a live website.

The purpose of these validations is not to make publishing more difficult. They exist to help content creators identify and correct issues early, when they are typically much easier to resolve.

Finding Accessibility Issues in the Editor

To help content creators address issues quickly, accessibility validation is built directly into the editing experience.

Reviewing Issues on Individual Blocks

When a block contains an accessibility issue, it will be highlighted with a coloured outline:

• Red indicates an error that must be corrected.
• Yellow indicates a warning that should be reviewed.

Selecting the block will reveal a red or yellow accessibility icon in the block toolbar. Clicking this icon displays detailed information about the issue or issues associated with that block.

Reviewing Issues Across the Entire Page

For a top-down view of accessibility issues across an entire page or post, click the red or yellow accessibility icon located in the upper-right corner of the editor, near the Save or Publish button.

This panel provides a consolidated list of accessibility issues identified throughout the document and allows you to quickly navigate to the affected blocks.

Common Accessibility Validations

The following list highlights some of the accessibility validations currently performed within cutheme. This is not a complete list and may change as new validation is added.

Headings

• The first heading in page content must be an H2.
• Heading levels must not be skipped.
• Consecutive heading hierarchy must be maintained.

Images

• Most images are required to have alternative text
• However, an option to mark as decorative is available
• Image alternative text should not exceed 125 characters in length
• The images alternative text and caption should not match
• Alternative text will be checked for generic patterns such as 鈥淎 picture鈥� or 鈥淎n image鈥�

Buttons

• Buttons are required to have text and a link

Table

• Tables are required to have a heading row

Content Titles

• Pages, posts and other custom post types are required to have a title

We Welcome Feedback

While accessibility requirements themselves are not negotiable, we are always looking for ways to improve the authoring experience.

If validation messages are unclear, difficult to understand, or lack sufficient guidance, we want to hear from you. Feedback helps us improve error messaging, documentation, training materials, and the overall workflow for content creation.

Many of the improvements introduced over the last several releases have come directly from feedback provided by content creators. That feedback continues to help us refine both the validation system and the supporting documentation around it.

Our goal is not to make publishing more difficult. Our goal is to help content creators identify accessibility issues earlier, provide clearer guidance on how to resolve them, and ensure that the content published on 杏吧原创 websites remains accessible to everyone.

The post Understanding Accessibility Validation in cutheme appeared first on cutheme docs.

Good headings make your content easier to read, easier to navigate, and easier to find. In just a few minutes, you can improve your page by using headings correctly.

Why Headings Matter

Headings help visitors quickly scan a page and find the information they need.

They also:

• Improve accessibility for screen reader users
• Help search engines understand your content
• Break up large blocks of text
• Make pages easier to read on mobile devices

Think of headings as a roadmap for your page.

Your Page Title is Already the H1

In cutheme, the page title automatically becomes the page’s main heading (H1).

That means you don’t need to add another H1 within your content.

Instead, start your page sections with Heading 2 (H2) blocks.

For example:

Page Title (H1): Undergraduate Admissions

H2: Admission Requirements

H2: Important Dates

H2: Tuition and Fees

Five Tips for Using Headings

1. Use Headings in Logical Order

Headings should follow a hierarchy.

For example:

H2: Programs

   H3: Undergraduate Programs

   H3: Graduate Programs

H2: Admission Requirements

   H3: Domestic Students

   H3: International Students

Each heading level supports the one above it.

2. Don’t Skip Levels

Try to move through heading levels in order:

H2 鈫� H3 鈫� H4

Instead of:

H2 鈫� H4

A clear structure helps assistive technologies understand your content.

3. Don’t Use Headings to Make Text Bigger

A heading should indicate a section of content 0 not be used for formatting.

Instead of choosing a heading because you like how it looks, ask:

Does the text introduce a new section?

• If the answer is yes, use a heading.
• If not, use regular paragraph text or another formatting option.

4. Make Headings Descriptive

Good headings tell visitors what they’ll find next.

Clear headings help both people and search engines understand your content.

5. Break Up Long Pages with Headings and Subheadings

If your page contains several long paragraphs without headings, visitors may struggle to scan the content. Adding headings creates natural stopping points and makes pages feel more approachable.

A good rule of thumb: if a section covers a new topic, give it a heading.

Quick Heading Checklist

Before publishing a page, check that:

• The page title clearly describes the page topic
• Major sections use H2 headings
• Subsections use H3 headings when needed
• Heading levels follow a logical order
• Headings are descriptive and meaningful
• Headings are used for structure, not appearance

Final Tip

Try reading only the headings on your page.

If someone can understand the main topics without reading the full text, you’ve probably created a strong heading structure.

It’s one of the simplest improvements you can make for readability, accessibility, and SEO all at the same time!

For more guidance on creating accessible headings, see our web accessibility article, Create Proper Subheadings.

The post Using Headings Properly: A Quick SEO & Accessibility Win appeared first on cutheme docs.