WorldSpace Project Issues

Project issues can be found through the Project Dashboard, viewing page specific issues via Pages section, or seeing the entire list within the Issues section: all are accessible via the main navigation bar. For this example, we will be looking at issues both within the Pages section, and drilling down further in the Issues section.

Viewing Page Issues

If your team relies on assigning pages to particular members, then viewing issues by Page may be more suitable for your work flow. The Pages section will display only pages that have been included within the limits of the scan. Though the metrics of the scan can be changed to better suit a team's needs, it is generally not-advised to attempt to scan all pages within the website.

Filtering Pages

Example of issue filter for Pages menu

The Initial Scan is generally limited to 2-3 clicks into the website, or has a cap of around 1000 pages. Normally these basic scans turns up around 50-100 pages. WorldSpace gives the following metrics to help filter for specific pages, or pages that hosts particular issues:

  • URL Contains: To search for any specific string within the url for a specific page, or possibly a directory. Examples include staff, news, etc.
  • Page Status: Filters pages based on their status labeled by either the scan, or by a user.
    • Completed: A page that has been fully scanned.
    • Other Domain Ignored: A page not analyzed due to the domain restriction. Due to the nature of the Rutgers domain being used on almost all Rutgers facing websites, restrictions are put in place upon first scan.
    • Fetched: A page that has been found, but not analyzed. It may not have been a page capable of being scanned, or has not been fully analyzed due to a currently running scan.
    • Failed: Generally these pages were not scanned due HTTP errors between the 400-500 ranges.
    • Archived: A page is archived if all the errors have been marked as Fixed or Ignored.
  • Excluded: The scan has the ability to exclude domains, directories, or specific pages. Those that fall under these criteria are marked as excluded here.
  • Description: Searches for pages that have one or more issues related to the specific description of the issue.
  • Script: If a script was used to identify pages during scan, they will be filtered.
  • Page ID: Filters pages that have been marked with a specific record ID.
  • Template Pages: Pulls pages that have been marked as templates.
  • From Active Scan: Pulls pages that went through the most recent scan.
  • Health of Pages: Pulls pages based on it's health level, a metric of WorldSpace Comply. The health is calculated by the highest level issue that was found. A first time scan may include majority Critical pages with a few Good pages.
  • Page Group: Pulls pages that have been found within certain Page Groups.
  • Issue Group: Pulls pages that have issues contained within a certain group, such as hyperlinks, color, images, etc. This is generally a much more broad scope for filtering, versus Description.
  • Potential: Initial listings only show pages that include Violations. Clicking this will also include pages that only feature Potential Violations. In WorldSpace Comply, a Violation is an issue to which the system can tell in the code that it violates web accessibility practices. A Potential Violation requires a manual check of the code or the workflow of the page before it can be deemed as resolved.
  • Manual Only: For issues included via manual upload.
  • Clean Pages only: Pulls pages with no issues found.

Please also be aware that the filtering system is not perfect, and may not export results as you would have expected. There is a learning curve when it comes to working with the filter that may require time and experimentation to understand how you can be utilize its features.

Drilling into Specific Pages

The listing of pages can be an incredibly helpful tool to figuring out not only where your most offensive pages are, but also where your redundant issues in your template can be found. To understand this, we will examine the page data, and then drill down into one specific page and break down the parts that the system provides. This example is from an actual rutgers.edu scan.

From the Pages section, the list is presented as follows:

Example of filtered list with URLS and open issues

  • The URL gives us the full link to the website. Clicking into this link also allows us more specific data on the page.
  • Only open issues are listed here, but two numbers are presented: including and excluding potential. Potential issues will require a manual check that the system cannot provide.

After looking at the overall issues, a trend appears: 40% of the pages have 8 issues, and is the lowest number found. It is safe to assume that these 8 issues most likely appear on every page and therefore are within the template. If so, it means we can reduce 8 issues from every page and remove almost half of the total issues presented in this scan.

For now, /about/traditional-songs will be a good baseline test, so we click the hyperlink to see more data on the page.

Screenshot of page details from about/traditional-songs

On the drilldown page, we're given further information about the page collected by the scan, including the following:

  • The ability to visit the page directly, where utilizing a localized scanning addon might aid in finding the issues: Deque has two developed that are available for download: FireEyes II for Firefox, and the Attest DevTools for Chrome.
  • The status of the page.
  • The Number of open issues.
  • The Number of fixed issues.
  • The entire code content of the page that can be captured through <HTML>. (Depending on the scan, this information may not be available
  • All the open scan-found issues on the page, which includes:
    • Who they are assigned to.
    • Labels if they have been assigned one.
    • The Issue Description with a More information button to learn more about the specific issue and how to solve them. By clicking into this link you are able to drill down into the issue. More can be learned in Drilling into Specific Issues.
    • The severity of the issue.
    • The specific HTML code to which is associated with the issue.
    • Their HTML tag type.

With this information available, we can tackle specific issues one by one, or assign them to members who may be better suited for them. Hopefully by identifying these issues, we can move onto the next set of most common items represented by the pages, and tackle them bit by bit.

Viewing all Issues

When your scan finishes it's run, it will list a series of issues found on every page based on the metrics of the scan. It is good to remember that in initial scans, many of these issues will be redundant. Issues that are found within the framework of the website, such as the navigation or footers, are therefore repeated on every scanned web page will be counted.

Listed issues within the Issues menu

WorldSpace comply gives you the ability to filter issues by type, view them in source code, learn more about why they are violations, and assign them to other members of your teams.

Filtering Issues

Example of issues filter inside Issues Menu

A scan can easily result in several hundred or thousand issues, which may be intimidating during an initial scan. To better dissect the data, utilizing the filter will aid in targeting particular pages or errors. There are multiple means of doing so, all of which can be used individually, or combined.

  • URL Contains: Inserting a word here will allow you to search for specific pages, or pages within a certain directory, like staff, news, etc. Unfortunately, the issues results do not display the page URL, which requires diving into the issues itself to see what pages are related to which issues
  • Severity: In this case, severity is divided between Violation and Potential Violation. In WorldSpace Comply, a Violation is an issue to which the system can tell in the code that it violates web accessibility practices. A Potential Violation requires a manual check of the code or the workflow of the page before it can be deemed as resolved.
  • Labels: Your team may establish labels for violations, and can be searched here.
  • Page Group: If Page groups have been established for your project, they can be searched here. This is good for teams tackling particular page types, and the issues are assigned thusly.
  • Description: Sorting by description means sorting through the issues based on the description of their violation.
  • Script: If scripts were developed to find certain issues, they can be filtered out.
  • Priority: These are in regards to the priority of the issue, critical, serious, moderate, or minor.
  • Scope Definition: If issues are found with a defined scope definition, they can be filtered here.
  • Tag Type: For filtering out a particular HTML tags that may have issues, such as img, a, div ect. It however does not filter user generated HTML fields, or defining characteristics within HTML such as href, class, role, ect.
  • Status: Looks for issues that are Open, Fixed, or Ignored.
  • Assigned to: The scan will only look for users who are within the project itself, but also has the dropdown based on email and not on their first or last name.
  • Issue Group: Looks for issues based on specific types of labels used within WCAG and other areas of accessibility.
  • Manual Only: For issues included via manual upload.
  • Common Only: For issues found in what may be considered ‘templated' areas of the page. These are the issues that may be found on every single page because it was designed into the repeated framework.
  • Remediation: Separates issues based on if the system has a quick and easy means of remediating the problem, or if it requires a more manual check and remediation.

Please also be aware that the filtering system is not perfect, and may not export results as you would have expected. There is a learning curve when it comes to working with the filter that may require time and experimentation to understand how you can be utilize its features.

Drilling Into Specific Issues

When looking at specific issues, the scan results provide a wealthy, and sometimes overwhelming amount of information. Pairing this with several hundred issues can make the results intimidating. However, by understanding how to utilize the information provided to find a solution to the problem OR identify a false-positive found by the system.

To understand this, we will drill down into one specific issue and break down the parts that the system provides. This example is from an actual Rutgers.edu scan.

Issues table headers
Example of a specific issue with further details

From the Issues page, the violation is presented as follows:

  • The Element Source code shows us exactly where in the code WorldSpace finds the issue.
  • Currently, no one has been assigned to the issue.
  • Currently, no labels have been added to the issue.
  • The issue is considered Open and requires remediation or a manual check.
  • The description presents it as an alt tag content issue. By clicking theMore information button elaborates the WCAG 2.0 Guidelines regarding this issue, rules related to it, different examples of relation between alt text and images, and a few examples on how to remediate it.
  • The severity tells us this is a Potential Violation. The system is unsure of if this is a true accessibility issue, so it requires a manual check of the code.
  • It is considered an IMG issue via the tags. Duplicate, or incredibly similar code issues will have the same tag.

The details of the issue can be found by clicking on the link wrapped around the Description of the issue. The following page gives more specific details about the issue, as well as the settings that can be applied to it.

Details regarding the issue found on that particular page

Combined with the information given before on the list, the following items are added to the specific detail page:

  • When the issue was found.
  • What scan metrics were used to find the issue.
  • The issue's description with its grouping and priority, as well as the ability to dive down further with theMore information buttonThe ability to view or add comments.
  • The ability to view or add suggested remediation.
  • The page where the issue is located- and a quick link to see the page issues.
  • The elements XPath.
  • See and adjust its status.
  • The ability to view and assign the issue to a team member.
  • The ability to view and add labels.
  • Any other code information to which WorldSpace may deem relevant.

With the page information, I can visit the hyperlink of the website and view the issue in question utilizing a localized scanning addon. Deque has two developed that are available for download: FireEyes II for Firefox, and the Attest DevTools for Chrome.

Resolving the Example Issue

This issue was labeled as a "Potential Violation", meaning that it required a manual check.

The Description informed us that the issue is within the alt tag, and the text inside may not be meaningful. The Issue Help popup also explained what sort of text is to be used for certain types of images, and how to ensure the alt-text is sufficient if needed.

After checking the page, I realized the image in question was a banner image, and though it is decorative in a way, it provides a visual for the information related to the content on the page. The Alt-text itself is labeled as "Medical Students in class". Though it is simple, it does describe in a short, but effective means as to what the picture is.

Seeing this, I realized that the issue itself was a false-positive that required a manual check. With that done, I assigned myself the issue and set the status to ‘Ignored' so that other developers will know it has been reviewed by me.

Your team may set up and develop it's own workflow, but the Web Accessibility Team will happily aid you in understanding how to best utilize WorldSpace for finding your accessibility issues.