[Digital Accessibility and Security Responsibilities for Websites]
[Cornelia Bailey:] Welcome to Digital Accessibility and Security Responsibilities for Websites. [January 2021]
I am Cornelia Bailey. I work in IT Services, and for the last two plus years I have led a program to reduce IT risk.
Today's presentation is the starting point for orienting University faculty, staff and students on the why and what of the new policies and explaining the practical implications.
I am joined by my colleagues, Ben Rissman, AVP for Digital Communications, Liz Honig, Director for the Office for Access and Equity, Pat Kogos, the Director of Digital Accessibility for IT Services, Jason Edelstein, IT Risk and Compliance Program Manager, IT Services, and myself.
Here's what we are going to go through today.
First off: Why are website security and accessibility important?
The web policies and standards.
Security and maintenance fundamentals.
Digital accessibility fundamentals.
An action plan.
And then time for Q&A.
Please keep in mind that after the forums wrap up January 29 we will be contacting forum attendees with updated documentation including answers for questions we might not be able to answer today.
[The Importance of Website Security and Digital Accessibility]
So, let's talk about the importance of website security and digital accessibility.
[Website security and digital accessibility at UChicago]
Web properties are websites and applications the University uses for academic, research, and communication purposes. We have more than 5000 web properties.
The security of these properties is of vital importance to the University, as is making web content accessible to all members of the community.
With this in mind, in 2018, the Provost charged IT Services with remediating risks associated with web properties and implementing standards that enable the University to sustainably manage these properties going forward in a secure and inclusive manner.
One thing you are going to hear over and over again is that this is a process. This is not a one and done situation. Going forward we want to make sure people have a process ongoing mindset when it comes to web properties.
IT Services has partnered with the Office of the Provost's Equal Opportunity Programs, Student Disability Services, and University Communications, and we have worked with faculty, IT leaders, and staff from across the University to gain alignment and address accessibility needs with new resources.
[What could happen if a web property is not secure?]
[Jason Edelstein:] Hi, everyone. Jason Edelstein with the Information Security team here, part of IT Services.
What risks could unsecured web properties pose?
Even if they don't have sensitive information or are critical to your departmental operations, insecure websites could pose risks when attackers compromise them, use them to host malicious software or viruses, or perhaps use them to launch attacks on other parts of the University community.
In addition, if they do host sensitive information, breaches, exposures, or defacement such as a website run by the University presenting a message that the University does not support, are other kinds of risks.
These risks could result in negative publicity or harm to the University's reputation.
Your website could also be taken off-line by the information security team, interrupting your business operations or taking it out of commission during an important part of the year for students.
We will talk more about what you can do to prevent some of these risks later in the presentation.
[Why is digital accessibility important?]
[Pat Kogos:] Hi everyone. I am Pat Kogos, the Director of Digital Accessibility in IT services. We are going to talk a bit now about why is digital accessibility important.
Our web properties should be easily navigated and understood by a wide range of users, including users with disabilities.
Offering sites that consider digital accessibility from the beginning offer a better user experience for everyone. Digital accessibility and usability are often hand-in-hand.
They also strengthen our commitment to an accessible, diverse, and inclusive working and learning environment.
Our digital representation online should reflect our academic excellence.
It also strengthens the University's compliance regarding accessibility laws such as the Americans with Disabilities Act and Section 504 of the Rehabilitation Act of 1973, and it reduces our risk in this space. There has been a lot of action in the legal world regarding inaccessible websites, and we want to make sure we reduce our risks.
Also, creating sites that consider digital accessibility and meet those standards, it enhances search engine optimization. This is just a great byproduct of doing the right thing.
Just know that there are lots of benefits to creating accessible sites.
[Web Policies and Standards]
[Cornelia Bailey:] As part of providing clear direction and expectations, the Provost announced two policies governing University web properties, and we are going to talk to them now.
[New UChicago web policies and standards]
Two new policies have been created. You can find these at the web address listed there.
The Web Properties Management Policy and the Digital Accessibility Policy. These two policies support the University's priorities of inclusiveness, security, and academic excellence. They apply to any unit, school, division, department, group, or individual that has or manages a University of Chicago web property. Think of the policy as the what to do.
I am also going to talk about standards. Standards are the how to do it. In this case, accompanying standards explain how to meet the policy's goals.
One new set of standards supports both policies. In other words, if you go to the Web Property Management Standards, found at websites.uchicago.edu, you are going to find more detailed information about what it means to meet the policy, the Web Properties Management Policy and also the Digital Accessibility Policy.
[Web Properties Management Policy]
The Web Properties Management Policy says four things.
The University web properties should be secured and maintained, so the expectation that content management systems, servers, and custom code be up-to-date.
They should be accessible to all users, including users with disabilities.
They should follow standards for domain names, where to apply for a domain name, guidelines for choosing a domain name. You can see the details about this at websites.uchicago.edu.
And they should be registered by a short form asking for basic ownership, platform, hosting of the website, and other types of data. Again, you can see websites.uchicago.edu to register the website. This is especially important when there are security or accessibility concerns. You would be surprised at how hard it is to find the owner of a website so that we can make contact with them.
[Digital Accessibility Policy]
[Liz Honig:] Hi everyone. Liz Honig, Director of the Office for Access and Equity.
The Digital Accessibility Policy essentially says a few things.
One, it requires that University web properties and content be made accessible. And how the University defines web content and properties, how they are made accessible, will be set forth in the standards which Pat will speak to shortly.
New web properties, or those undergoing substantial revisions or redesign after September 1 of this year, are required to conform with the standards. They are required to be made accessible.
New digital content must also conform with the standards and be made accessible after September 1 of this year as well.
With respect to existing content that does not undergo substantial revisions, redesign, or with new content, then we expect that site owners make best efforts to reach and adhere to the standards.
With the understanding that at the end of the day it is important that all of our web content be made accessible. And so, if someone with a disability makes a request for content that they can't otherwise access because of their disability, we expect that the site owner will make that content accessible in a timely manner either by bringing that content up into conformity with the standards or by providing an alternative format.
The Associate Provost for Equal Opportunity Programs, as well as the Chief Information Officer, both have responsibility for the Digital Accessibility Policy.
[Do these policies apply to my website?]
[Cornelia Bailey:] Since the announcement, we have been receiving a lot of questions about: Do these policies apply to my website?
I will go through the basics of that and if you have more specific questions you can ask them in the Q & A.
The policy applies to any University web property, that is, any website or web application owned or controlled by the University or operated by or on behalf of the University.
So, examples include a website using a University domain name, or a website redirected from the University domain name. Domain names include uchicago.edu, chicagobooth.edu, those are the chief ones, there may be a few others in play.
The second case is a website without a University domain name and is not redirected from a University domain name, but is used for University business. University business includes, but is not exclusive to teaching, publishing research, marketing University events, University groups, and research labs.
So, if you have a website that does not have a UChicago domain name, let's just say ProfessorX.squarespace.com, but you use your site for teaching, you send students there to get materials, to read up on stuff, that is University business, and your website is subject to these policies.
Also, if your website doesn't use a domain name, isn't redirected from a domain name, but uses University branding and logos, that is a University web property.
When do these policies not apply?
The policies may not apply to some web properties, even if they reference the University. Examples include a website without a University domain name that does no University business or bears University logos.
So, let's say another professor's site, with no branding, only CVs, photos, blog, et cetera. This is not subject to the policies.
If a web property is not subject to University policies, the site owners should still ensure that the property is accessible, secure, and maintained. These practices benefit the owners and reduce risk to reputation and security. In other words, everything we are talking about in the policies and standards is a really good practice no matter who owns the website.
And, if you have questions afterwards, please contact firstname.lastname@example.org.
[Security and Maintenance Fundamentals]
[What makes a secure web property?]
[Jason Edelstein:] Hey, everyone. It's Jason again.
Let's talk just a little bit about maintenance for security when it comes to web properties.
What are some good practices?
First of all, when you have a web property, it is important to make sure it is using supported, actively updated and patched technology. For example, if you run a website on the Drupal content management system or your website uses supporting software from Microsoft, Oracle, or other types of vendors, you need to make sure that all of those pieces are actively updated, patched, and secure.
This can be tricky because it is important to remember that websites will be used for several years. It is not just a one and done project. So, if you are using a partner to design your property or host it, make sure that you have ongoing maintenance budgets and you are aware of how to patch or maintain these products, and whether your provider is doing that work for you or you need to find someone to help you execute that work yourself.
Critical patches, those with the highest levels of severity, are typically announced by vendors. If you are responsible for your own maintenance, keep track of when critical security fixes are released and apply them as soon as possible, but no later than 30 days. The information security team at the University of Chicago will often announce if there is an especially severe patch that needs to be applied. And may ask that you apply it as soon as possible because it is being actively used to compromise websites.
If you are developing your own code, it is important, as well, to make sure that you develop securely. Things like SQL injections or other kinds of exotic sounding security vulnerabilities can be easily coded against and protect your property from being attacked.
We recommend looking at the OWASP Top Ten Project. Links will be provided for the website. And follow standard, secure coding practices when doing your own development.
And finally, if your website is taking money such as credit card payments, make sure that you work with the bursar's office to ensure that your website is PCI compliant. This is an important framework that is mandatory whenever credit cards are being handled, and it may substantially increase the amount of security your website requires.
[What do website owners need to do to comply?]
As I mentioned, since websites can be used for several years, when engaging in new project work for a web property have a budget and think about the trajectory for your property going forward. Who will be maintaining it on behalf of your group or unit? What happens if they leave? Do you know where all of the passwords are?
It is important also to take quick action if you are notified. For example, do you know how to get in touch with your provider? Do you know what their processes are?
And if you have any questions at all about this, feel free to reach out to the information security team. You don't have to wait for us to get in touch with you. You can e-mail us at email@example.com or give us a call [773.702.CERT].
Thank you very much.
[Digital Accessibility Fundamentals]
[Pat Kogos:] This is Pat Kogos again. We are going to talk about digital accessibility fundamentals.
Who is impacted if content is not accessible?
Users with disabilities are impacted. For instance, people who have auditory disabilities like deafness and hard of hearing, cognitive impairments such as dyslexia and attention deficit disorder, motor impairments like arthritis and muscular dystrophy, neurological disabilities like epilepsy and migraines, speech impairments, and people who are visually impaired, blind, and colorblind.
A lot of other users are also impacted. People using various screen sizes sometimes with a fixed view like a mobile phone or an iPad, older people with changing abilities, users with temporary disabilities like if you have a broken arm, broke a hand, you've had eye surgery. People with situational limitations, so if you are out in the bright sunlight and trying to see your screen or if you're in a loud environment and cannot hear. Users with slow Internet connections whose images may not load, and anyone with assistive technology like a screen reader.
Disabilities by the numbers
At UChicago our disability statistics in the undergraduate population are that 8% of our students have registered a disability with Student Disability Services, and 18% self-identify as having a disability.
In our graduate and professional population 3% of students have registered a disability with SDS, and 13% self-identify as having a disability.
This is as of spring 2019. Also, we included data from the 2016 Campus Climate Survey.
The interesting thing to note about these two is that it does impact a large number of people, and there is 10% of students in each of these populations that self-identify as having a disability but don't register it with Student Disability Services. We want to make sure that everyone has equal access.
In the U.S., the disability statistics are very similar. One in five people in the U.S. have a disability. This equates to large numbers of people. 8.1 million people have some form of visual impairment, including 2 million people who are blind or unable to see. 7.6 million people have difficulty hearing, including 1.1 million people whose difficulty is severe. 19.9 million people have difficulty lifting or grasping objects. This is from the U.S. Census of 2010.
How do people with disabilities navigate websites?
They often employ assistive technology to interact with digital content, including websites. Some of the examples of assistive technology are screen reader software, and we will talk about some of those specific screen readers in a little while, pointing devices like head pointers, alternative keyboards, including refreshable Braille, eye gaze technology, and voice recognition software. On this slide we have an image of a refreshable Braille keyboard and a head pointer.
[Basic principles of digital accessibility]
There are some basic principles of digital accessibility that will help you to get started and understand the kinds of things that you can do in order to make your site accessible.
One of them is to create appropriate alternative text, sometimes called alt text, for images and controls. That way someone who can't see the image understands what the image represents.
If your headings are marked up properly using proper semantics and nested in hierarchical order, H1 followed by H2, followed by H3, this will help people who are using screen readers because they can jump from heading to heading and scan a page in order for them to understand which content they are most interested in diving into further. If we just create headings that are bigger and bolder or using different fonts, that will not help a screen reader to use those properly. We need to use proper markup.
Captions, transcripts, and audio descriptions for multimedia are very important, super critical, including social media posts. Please include those kinds of things before you post your social media.
Sufficient color contrast will also help people who are colorblind or have low vision. So, the text should be sufficiently different in color from the background, the link text against the surrounding text, and interactive elements against the background. There are a lot of great color contrast tools that are free that we can use to check these kinds of colors. Again, we can talk about that as we move forward, but we have a lot of these tools on the Center for Digital Accessibility website, which we will discuss later as well.
Color alone should not convey meaning. So, if you're going to use red to indicate an error, that's fine as long as you also use text or some other indicator to also say there is an error. So anyone who is colorblind will not miss out on that meaning. That also applies to things like graphs and charts. If you're going to be using color in your graphs and charts, which is very common, you should also use either a pattern or some sort of text that goes along with the color so people who are colorblind can still understand it.
Using meaningful link text is an easy thing you can do in order to really create a lot of impact. So, describe where the link will take the user. Don't use the terminology "click here." And don't use the URL as link text. Users who tab between link text will hear those phrases, and that is all they will hear, and they won't understand where that link will take them. The URL, if it is being read out by a screen reader, is often read one character at a time, which is painful and not helpful. So again, make sure you use meaningful text, something similar to "Visit the Center for Digital Accessibility website."
Visible focus indicators to show where a user is tabbing through a webpage are very important for people who are using keyboards. Some people cannot use a mouse and they rely entirely on their keyboard. So if they are tabbing through content, there should be an indicator, it's usually a colored box, surrounding what is in focus. That way they can know where they are on the page. Without this focus indicator it's extremely difficult for someone using only a keyboard to navigate.
All text can be resized up to 200% without loss of content or functionality. Again, this is very helpful for users with low vision.
Accessibility is often abbreviated a11y pronounced ally. It was derived by replacing the middle 11 letters of the word accessibility with the number 11. You will often see this when you read things about accessibility, particularly in the social media space where every letter counts.
[How do screen reader users access content?]
So, we talked a little bit about screen readers. It's interesting to note how screen reader users access the content. According to a recent screen reader survey, most screen reader users find information on the webpage in the following ways, by order of frequency. They often utilize hotkeys to access navigation features.
So, the most preferred way of navigating is through headings, as we discussed earlier. So make sure they are marked up properly.
They often use the find feature, as all of us use, control-F to find something on the page. If you have text hidden in an image, the find feature will not work. So, if you have text on an image, make sure it is also on the page somewhere.
Then they often read through the page beginning to end.
They navigate through links as we have discussed, so create that meaningful link text.
And they navigate through landmarks and regions. Landmarks and regions can be set up in your ARIA, so that's a great way for them to go to, for instance, go straight to the main content of the page.
This survey was done by WebAIM. It was their user survey number eight. WebAIM is a nonprofit based at Utah State University, and they have been operating in this space, and they have been leaders in the digital accessibility world for a long time. If you see any resources from them, they are a trusted group of people.
What standards are used to assess web accessibility?
The Web Content Accessibility Guidelines, referred to as WCAG, were developed by the World Wide Web Consortium, the W3C, which is a group that develops international standards for the web. WCAG includes three levels of conformance.
Level A, which is the most basic and has the highest user impact.
Level AA, which is the industry and UChicago standard, and it includes Level A.
And Level AAA, which is the most stringent and the most difficult to achieve.
The current version of WCAG is 2.1, and it was adopted in June 2018. WCAG 1.0 was adopted in May of 1999, so these standards have been out there for more than two decades.
To meet the University's digital accessibility standards, all web properties shall comply with WCAG 2.1 Level AA, and they should have an "Accessibility" link in the footer that links to accessibility.uchicago.edu. That goes to the Access UChicago Now website.
As far as legal guidelines go, we discussed a little bit about the Americans with Disabilities Act, and the Department of Justice has continually reaffirmed that the ADA of 1990 applies to websites as "places of public accommodation." WCAG is not mentioned in the ADA, but the WCAG guidelines are consistently upheld as the standards by the Department of Justice and the court system.
This is from the Bureau of Internet Accessibility, "Is There a Legal Requirement to Implement WCAG?"
For a long time, the federal government discussed creating their own standards, but in the absence of that they have been using WCAG, and I think the understanding is that now they will just going forward continue to just use WCAG.
There is also, in addition to the legal side of things, we also really want to keep in focus that we are doing this because we are committed to a diverse and inclusive environment, and we are committed to access for everyone.
So this quote helps us to reset that: "How many opportunities do we have to dramatically improve people's lives just by doing our job a little better?" This is from Steve Krug, the book "Don't Make Me Think: A Common Sense Approach to Web Usability."
So the legal risk and the opportunity to do better are both two sides of the same coin.
[Evaluating web accessibility]
As far as evaluating web accessibility goes, there are a lot of free automated tools available to help. So, tools that assess your website, identify less than 50% of issues, but they are a great start.
In addition to using those tools, you can also provide and do manual testing which really must be performed in order to find the rest of the issues.
One of the easiest things you can do is just do your own keyboard testing. Put your mouse aside, don't use it at all, and see how easy it is to navigate and use all the functionality of your website. Everything should be accessible using only the keyboard.
The most common keys used for navigation are Tab to move forward, Shift+Tab to move backward, arrow keys, the space bar, and Enter.
Screenreader testing is also done, and this takes a little bit of practice. You will want, when you are first getting started, to create settings in your screen readers to help you move slowly and then you can increase your speed as you move along.
The most popular screen readers for windows are JAWS, and there is a cost associated with that. NVDA is free. If you want to get started and you have a Windows-based machine, NVDA is a great free way to get started. Apple products have VoiceOver included, and most operating systems do have a built-in screenreader.
[Digital accessibility as part of the process]
We really want you to create a process, your processes around, to include digital accessibility. Planning for digital accessibility and building it into our processes is so much more efficient and effective than trying to remediate accessibility issues after the fact.
There are lots of statistics out there about how many times more it takes. For instance, if it takes you five minutes to do something on the lead end, it would take a half an hour to fix something on the tail end. This is really important to note.
It should just be built into our processes. We shouldn't think of digital accessibility as a project in which we are going to get our site to a state that's accessible and just leave it alone. Every time we add content to it or make any tweaks to our site or the guidelines change, then we need to constantly stay engaged with the work that we put out to the world.
We are also responsible for the accessibility of all the systems we offer, whether developed by us or an outside vendor. So, we really need to consider things that we procure in light of accessibility. We need to ensure accessibility and budget for the related expenses throughout the procurement of all our third-party systems.
Our software and web development, including ongoing maintenance. When we are creating documents and maintaining them, including PDFs, they should be accessible. Our media and social media creation, including descriptions of images, video, and audio. Again, we should have all of those things, especially in social media, accessible before we post.
Instructional design should also consider accessibility, as well as project lifecycles, and webinar and remote meeting planning. If you're going to have a webinar like we are having today with a wide audience, make sure you include a captioner, as we have today.
We usually add a statement saying that if anyone needs additional accommodations, please let us know, so that you can be prepared to also have an interpreter if needed.
Who is responsible for digital accessibility?
The short answer is that we all are, but site owners have primary responsibility for ensuring that the web properties they are responsible for conform to this policy. They also have responsibility for educating and training people who contribute to those sites on the requirements of the policy and the tools and methods for conforming with it.
The site owner is defined as an individual designated responsible for one or more University web properties.
But the site owner is not alone in this. The University has provided resources to support digital accessibility, including the Center for Digital Accessibility in IT Services.
[Get started with digital accessibility]
There are some great ways you can get started with digital accessibility.
The first thing is to learn more about website accessibility. We have a lot of great resources, as I mentioned before, on the Center for Digital Accessibility website. There are also a lot of really trusted resources out in this space.
Don't be intimidated or worried that the task is too daunting. Make a best effort by focusing on removing barriers. We want to make sure there are no barriers to reaching our content. Then you work toward greater accessibility over time.
Start making some of the easy changes first. For instance, replacing missing alt text for images and interactive elements is an easy change. Also, replacing or adding missing captions and audio descriptions, is also easy and fairly low cost. You can often do it yourself. Headers that aren't marked up properly can be fixed. Address color contrast issues and missing focus indicators.
Then, site-wide issues. For instance, if your link style doesn't have an underline and your link color is not sufficiently different from the rest of your text color, if you make that change in one location, it will apply to your entire website. That is a really important thing to tackle early on, as well as any issues that are in your header or footer. Again, once you fix them once they will appear throughout your site. So those are very important.
Then, prioritize issues with the highest user-impact. For instance, if you can't use part of your site when you are using the keyboard, or if using your keyboard ends up in a space that's what they call a keyboard trap, say you are tabbing through your content, and it gets trapped on a certain thing, you want to make sure you remove all of those kinds of barriers.
Again, any new website or content should be a priority.
[Resource planning and support]
[Liz Honig:] Hi, everyone. Liz Honig again from the Office for Access and Equity.
So, what University resources are available to support you as you implement these new policies? There may be costs associated with making some changes to get into compliance with both new policies. As a first step, we encourage you to plan and to discuss any potential costs with your unit budget manager as you would any other anticipated costs related to your websites and the work that you do.
There are many things that you can do to bring you into compliance with both policies at little to no cost. With respect to security, Jason spoke to some of these but reducing risk, making simple choices about product configurations or data which can help you avoid compliance or incurring additional security costs.
With respect to digital accessibility, starting with some of the quote-unquote easy changes that Pat noted such as adding alt text to your images and creating meaningful link text. Instead of "click here," describing what you are linking someone to, are easy and little to no cost ways to help you come into compliance with the policies.
In addition, the University has provided organizational resources to help you come into compliance with these policies. One through the Website Resource Center, which Ben will speak to shortly, and another through the Center for Digital Accessibility, which has a number of incredibly helpful tools, videos, resources. I think you could spend all day on that website.
Thirdly, through an enterprise accessibility tool called Siteimprove that Pat will also speak to.
[Website Resource Center]
[Ben Rissman:] Yes, so we know that a lot of new information has been presented today and additional details or resources may be needed for your website. So, with that in mind, we launched this Website Resource Center at websites.uchicago.edu.
The goal of the site is really to provide a more in-depth information for you and access to some of the resources available around campus. So if you need to look up these web policies and standards, this is the place to go.
It also has an easy way to register your website, if you are looking for a new domain name that is needed outside of your unit's domain, we have a link here where you can put in a request.
Also, we often know that people are looking for different hosting options for their websites. We have some that have been set up with the University which may be of interest to you.
There is a number of training and support materials on this website as well. So, depending upon what you are looking to do, that could be very helpful for you.
Also, as I think was mentioned earlier, we are going to be updating the website with commonly asked questions that we are hearing throughout these different sessions. You can look for those in the next coming weeks.
Then, for anyone who is looking for an outside partner or looking for help with their existing site or for new sites, we have a preferred vendor group that we work with. They are kind of preapproved by the University Procurement, and they also are well aware of all of our policies and standards.
We highly recommend that you reach out if you are looking for additional support.
[Center for Digital Accessibility]
[Pat Kogos:] The Center for Digital Accessibility is a resource in IT Services. We have been here for a year now. We launched in January of 2020.
So, we provide services related to digital accessibility like consulting services, if you have any questions about guidelines or implementation of standards. We also do some evaluation assessment, as well as provide tools and support for assessment. So, if you check out the resources section of our website you will find lots of great free options.
We also provide training, customized training, as well as links to resources. On the CDA website we have some videos that we have created, as well, and we also offer live Q&A sessions that go along with our training videos. Please check out our website and join us for some of those sessions.
If you don't see what you are looking for, let us know, and we can meet with your group and address your specific concerns.
The staff of the CDA consists of myself and three digital accessibility specialists. We have two people who have been web developers for a long time and someone who has been an assistive technology specialist for a long time. We have a really dedicated and knowledgeable staff and can definitely help you with all of your concerns.
Our [CDA] website is digitalaccessibility.uchicago.edu. I encourage you to check it out.
[Enterprise accessibility tool]
The University has also procured an enterprise accessibility tool to help us all with this effort. And we have chosen Siteimprove to assist site owners, web developers, designers, and content editors identify and remediate accessibility issues discoverable via automation.
As we talked about earlier, there's a little less than 50% of the issues that can be discovered via automation, but using this enterprise tool will certainly help you with that effort.
Keyboard and screen reader testing should still be used to find and remediate issues discoverable via manual testing.
If you visit the CDA Get Started page you can learn more about manual testing.
Siteimprove provides a suite of web-based tools that regularly scans websites. It detects and reports on issues affecting accessibility, content quality, search engine optimization, and more. So although we procured it for the reason of accessibility, it does have a lot of other really nice features that I think website owners will really appreciate, including search engine optimization and including the ability to find broken links on your website.
It's a really powerful tool, and we encourage everyone to explore whether it is something that would be good for their website. But the web accessibility tools on it help you find and fix accessibility issues specifically using the WCAG 2.1 AA guidelines. It helps you set priorities for addressing accessibility issues, and it helps you schedule reports and track improvements over time.
Visit the CDA website to learn more about how to start the Siteimprove onboarding conversation. If you're interested in pursuing this for your site, not all sites will be a good fit for this, but we can help you to evaluate whether your site is. Please contact us if this is something you're interested in.
[Cornelia Bailey:] One other thing we wanted to spell out is kind of your action plan. This is kind of a timeline with the key steps that you should prepare to follow in the next few months.
First off, our policies were announced earlier this month. So that step is done.
The next step is for you to review the policies and standards. Again, I have covered the policies earlier. We talked about the standards, which is the how to follow the policies. I would encourage you to go to websites.uchicago.edu and look at the standards.
If you are a web property owner, we would like you to register your website and provide contact information of the people who are responsible for the website. Again, you can go to websites.uchicago.edu to register your website.
The next thing you should do is review your website using the standards as a guide. Specifically, the parts on security that Jason covered and the parts on accessibility that Pat covered.
If you have questions there is plenty of resources to get them answered, e-mails to e-mail, et cetera. But the important thing is for you to use the standards as a to do list to make sure that you are doing right by your website.
Then there's the actual work of remediating issues to improve safety and accessibility. As was said earlier, a lot of these might be very easy, some of them might be more complicated, but it's a good idea to get a sense of the work sooner rather than later. You might be pleasantly surprised that there is far less work than you feel like you anticipate.
Finally, like we said before, this is a process not a one and done. After September 1 we need you to continue to ensure the safety and accessibility of your websites and using us as resources to help you do that.
[For more information: Center for Digital Accessibility, Website Resource Center, Policies]
[Additional questions? General: firstname.lastname@example.org, Accessibility-specific: email@example.com, Security-specific: firstname.lastname@example.org]