How to Update ONRR.gov - DOI-ONRR/onrr.gov-site GitHub Wiki

How to Update ONRR.gov

So you need to update ONRR.gov. Congratulations! Before you know it, you’ll be updating different types of content on the site. However, before we get started, let’s review the background on what exactly makes up the site.

Structure

ONRR.gov is a website drawn from data stored in files that live in two different drives. You may have them named differently on your machine, for our purposes we’ll refer to

“ONRR2017 (\iondeniisp01)” as the “Y drive” or the “dev site”

“ONRR2017 (\isehrnpubstg01\websites”) as the “Z drive” or “live site”

The Y drive is the “development” drive; it links to an internal site that only people with permission and access to the ONRR intranet can view. To access the dev site, you will need to be connected to your VPN.

The Z drive is the “live” drive, and ONRR.gov draws data from it to present online. When you go to ONRR.gov, you are reading data from our team’s Z drive.

The Y drive is a pre-published version of the Z drive. Every file and folder on the Y drive will have a corresponding file or folder in the Z drive. They have the same names and the same locations.

To implement changes, make your changes in the Y drive and confirm them by looking at the dev site. If changes are correct, contact the requestor and provide them a link to the appropriate page on the dev site. Once they approve, copy the file from the Y drive and paste it over the contents of the same file in the Z drive. This pushes dev updates to the live site. Changes can take over 30 minutes to appear on the live site once files are saved in the Z drive.

Code

ONRR.gov is mostly built from files of three different programming languages: HTML, CSS and JavaScript.

HTML documents place information on the page. You’ll primarily work in .htm files of HTML.

CSS styles and organizes the information. CSS Zen Garden is a fun tool for exploring different ways CSS can style information on a page.

JavaScript is a script running language and has a wide variety of interactive uses; for our site we use a type of Java called JSON (JavaScript Object Notation) which helps with database interactions. Don’t worry too much about CSS or Java, since you’re only updating content on the page, you’ll only work within HTML.

HTML

HTML, or hypertext markup language, is a markup language used for web browsers. It uses tags to create HTML elements. Tags are written using angle brackets. <title> is a tag that defines the title of an HTML document.

HTML elements are made of tags. This is the HTML element for a link:

<a href=”helloworld.com”>Go to HelloWorld.com</a>

This is a link to helloworld.com, where the link text says “Go to Helloworld.com”.

If you are new to HTML, a great place to start is HTML trainings.

To edit HTML, open the file with Notepad. HTML files can be edited with more complex HTML editor software, but to get started a simple text editor like Notepad works. Notepad, text editors or HTML editing software are preferred because a browser will not read word processing documents.

HTML documents look like this: HTML is a markup language that web browsers use to interpret and compose text, images, and other material into visual or audible web pages.  It uses lines of coded text to communicate.

Updating Pages

To update content in a page, you’ll update text or links, comment out code, and run accessibility reports.

The lists provided on this page are for your reference; for ease of use, consider adding the appropriate list in your GitHub issue. To bring the check boxes over to your issue, click "Edit" and copy the text to paste onto your issue. This will bring your issue an ordered list with check boxes, which can help keep the (at times lengthy) process on track.

Updating Text

To update text, find the text you are replacing. This is easily done in the html doc with a Crtl+F search of the page for some of the text you are replacing. Find the text, replace it, and save the file. The dev site updates as soon as you save the file. Once saved, check the dev site for your changes. If the changes you implemented are correct, send the link to the dev site to the requestor for approval to post to the live site.

Once approved, copy and paste the file to the same location on the Z drive. Once you’ve saved the file in the Z drive, confirm on the live site that the text is updated. It will take about 30 minutes to show up on the live site. After it’s confirmed that it’s live, note in the issue that it’s live and close the issue.

Updating Text Checklist

  • 1. Open the issue on GitHub

  • 2. Open the correct .htm file on the Y drive with Notepad

  • 3. Find text that needs to be replaced

  • 4. Delete text

  • 5. Replace with approved copy

  • 6. Save file in the Y drive

  • 7. Get approval from the requestor to push to the live site. Do not push live unless you have verbal or written confirmation that everything on the dev site is accurate and there's no additional changes needed.

  • 8. If changes are effective, copy and paste the Y file over the file of the same name and location in the Z drive

  • 9. Confirm changes in the Z drive on the live site. You will likely have to clear your cache and wait 30 minutes or more for changes to appear.

  • 10. If the live site is correct, Post the link to the live site in the issue then close the issue

Updating Links

Links are made of text, a URL or web address, and HTML elements.

This is a link:

Free Code Academy

This is the HTML that makes up that link:

<a href="freecodeacademy.org">Free Code Academy</a>

If a link is being updated on ONRR.gov, it should be updated in the Content Audit tab in the Accessibility Tracking worksheet. This will amend the Content Audit to reflect the current state of the site.

If you are unfamiliar with what links are made of or would like to learn more about how they operate, spend some time doing some HTML trainings.

Updating Links Checklist

  • 1. Open the issue on GitHub

  • 2. Check the Content Audit tab of the Accessibility Tracking spreadsheet to identify the link's location and to see if the link needs to be updated in more than once place.

  • 3. Find the correct. htm file on the Y drive with Notepad

  • 4. Find the link that needs to be updated

  • 5. Replace with new link destination or update as needed

  • 6. Save file in the Y drive

  • 7. Confirm changes in Y drive on Dev site

  • 8. Send the requestor a link to the dev site changes and request their approval. Do not push live unless you have verbal or written confirmation that everything on the dev site is accurate and there's no additional changes needed.

  • 9. If approved, save the Y file over the file of the same name and location in the Z drive

  • 10. Confirm changes in the Z drive on the live site

  • 11. If live site is correct, post the address in GitHub and close the issue.

Commenting out HTML

Because we do not use a version control software for .html files, we generally do not delete content from the .html files. Instead, we comment out the HTML, using an HTML element around tags to prevents the tags’ internal pieces of code from loading.

This lets us keep the code so we don’t lose it, and can move it somewhere else or bring it back onto the page later.

To comment out HTML, use this format: <!--<element to be commented out>-->

To comment out a link, you’d add <!-- before and --> after the link. That would look like this:

<!--<a href=”https://www.freecodecamp.org/”>Free Code Camp</a>-->

This link to Free Code Camp would not appear on a page, because it has been commented out.

If you are struggling with commenting out, doing some HTML trainings is very helpful!

Commenting Out HTML Checklist

  • 1. Open the issue on GitHub

  • 2. Open the correct .html file on the Y drive with Notepad

  • 3. Find the element(s) that needs to be commented out

  • 4. Update .html file as needed

  • 5. Save file in the Y drive

  • 6. Confirm changes in Y drive on Dev site

  • 7. If commenting out links or links to documents, update the Content Audit tab to reflect the change.

  • 8. Send the requestor a link to the dev site changes and request their approval. Do not push live unless you have verbal or written confirmation that everything on the dev site is accurate and there's no additional changes needed.

  • 9. If approved, save the Y file over the file of the same name and location in the Z drive

  • 10. Confirm changes in the Z drive on the live site

  • 11. If the live site is correct, close the issue

Accessibility

In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C § 794 (d)) applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508, agencies must give disabled employees and members of the public access to information comparable to the access available to others.

Running Accessibility Checks

We check document accessibility to ensure that people of all ability levels are able to access the documents hosted on our site. If documents are not accessible, we contact the document owner and request they update the document to become accessible. Once we have an accessible version, we update it in the development site and contact the owner. Once the owner has approved changes in the development site, we push to live.

Checking the Accessibility

Here is a comprehensive guide to conducting accessibility checks on a PDF, with a checklist below.

  • 1. To check the accessibility of a PDF using Adobe Pro, open the document and select Tools > Accessibility > “Full Check.”

  • 2. When the "Accessibility Checker Options" screen pops-up, choose where you want the accessibility report to be saved. Keep all of the check boxes selected, and press "Start Checking."

  • 3. The results of the accessibility check will show in the panel on the left. If there aren't errors, you can post the document on the site. If there are errors, you will save the accessibility report in a PDF in order to share it with the requester.

  • 4. To create a PDF version of the accessibility report, go to File > Create > "PDF from File."

  • 5. Find the location you chose to save the accessibility report, and click on the html version of the accessibility report.

  • 6. The new pdf version of the accessibility report will open up. Save it with the same filename as the not accessible document, and send it to the requester (preferably through a GitHub issue) to fix the errors.

More Resources for Checking Accessibility:

Replace a Non-accessible Document with an Accessible Document Checklist

  • 1. Find the file you are replacing and copy the file name

  • 2. Open the accessibility tracking excel file in excel (not a web browser!)

  • 3. Find the File Column

  • 4. Click on the downward arrow to find the filter search bar (see below) To filter, navigate to the E column in the accessibility tracking spreadsheet and select Filter.

  • 5. Paste the file name in the search bar and press search.

If you don’t already have it, this will show you a pathway to where the file is housed on both the development and live site folders.

  • 6. Save the accessible PDF over the inaccessible PDF in the development drive.

  • 7. In the Accessibility Tracking file, navigate to “Current Status” and change “Not Accessible” to “Accessible”

  • 8. Send the requestor a link to the dev site changes and request their approval

  • 9. If approved, save the PDF file you saved in the development drive in step 6 over the file of the same name and location in the live site drive

  • 10. Confirm changes in the live site drive on the live site

  • 11. If the live site is correct, close the issue

To gain a better understanding of how HTML operates, check out Free Code Camp

Sign up with your GitHub account, and select “Start at the very beginning” or go to

https://www.freecodecamp.org/learn/responsive-web-design/basic-html-and-html5/say-hello-to-html-elements

Spend some time learning about HTML, the first five modules should take you a few hours and give you a workable understanding about how HTML operates.

⚠️ **GitHub.com Fallback** ⚠️