Assignment3: Accessibility (Writing Assignment 1)

Assignment borrowed from notes by Mark Liffiton

Hello, everybody! In addition to being a class focused on coding, CS253 is also a writing-intensive class. To that end, Assignment3 is our first "writing" type assignment. For this one, I will first outline what is meant by accessibility in web development, and then outline the expectations of this assignment. Assignment 3 is due on November 4, 2023 at 11:59pm CST.

Accessibility on the Web

Accessibility refers to the concept of "universal design". This is a way of designing websites which benefits everyone, not just users who may be disabled. Regarding users who may be disabled, these disabilities may include the following:

• Visually (i.e., blindness) - can use screen readers or magnifiers
• Hearing/Audition - can use captions or subtitles
• Motor - can benefit from larger targets on-screen

Other disabilities may fall under the categories of cognitive disabilities, color blindness, or photoepilepsy.

As some examples of how we might design a website to better accommodate individuals with disabilities, we can design our site for screen readers:

<img src="path_to_img.jpg" alt="alternate text description">
<a href="path_to_link" title="alternate text description">

When we design our site with accessibility in mind, we design it to be as usable as possible by as many people as possible. Of course, we still want our design to be intuitive, user-friendly, and easy-to-understand. Here are some other ways we can implement accessibility in our sites:

• Use of fonts to differentiate types of content - may aid those who have a visual or cognitive impairment
• Using semantic tags (and ARIA) to organize the page with meaningful labels attached to different chunks
• Describing images in text (captions) or using alt text
• Using captions in videos (ideally, manually created)

Assignment Description

This assignment is titled, "Evaluating the Accessibility of an Existing Website". The description is the following:

You are the new web developer at a local non-profit or government organization (you will choose a real website for a local organization to analyze). The CEO/head/board/leadership/etc. of your organization, along with the web development team working for you, know that “accessibility” is an important aspect of web development, but they have few details beyond that. Further, they are not sure about what the previous web developer did or did not do with the site to make it accessible. They are not familiar with any accessibility issues or the guidelines provided for them. They have asked you to analyze the site and provide a clear, coherent report on the state of the accessibility of their website and how it could be improved.

Specifically, you need to point out any issues you find, along with potential impacts and suggestions for improvement, and point to any positive examples of things that have already been done well to address accessibility, with explanations of what is positive about them.

Evaluate the site as a whole, not just the front page; certain "interior" pages may have accessibility related characteristics that are not found on the front page itself. Most sites will have a common design throughout, in which case any comments relevant to all or most pages can be made once and referred to later, rather than repeated. Focus the assessment of any pages beyond the front page on new details in those pages that are not already discussed earlier. If a site is too large, with too many different types of pages to assess all of it, focus on a set of pages you believe to be most important to users of the site, and make sure you look closely at at least three different pages.

Technical Writing

This report will be an example of technical writing, for which technical correctness and clarity are critical, especially when writing about new or complex concepts. Common aspects of good writing like writing mechanics, organization, and presentation are still important as well.

Please read the Technical Report Guidelines and Suggestions carefully. Nearly all of the points made there are relevant to this report, and the practices it describes will be the expectations for this report.

Additional points specific to this report:

• For the report to be useful, the reader needs clear examples of each website element you discuss. Include specific examples in your writing for all positive and negative features. It is best to illustrate each with a cropped screenshot of the site (focusing on just the relevant area, not showing the whole page) and/or a snippet of code, as appropriate for each.
• Regarding the point in the linked guidelines about avoiding "tedious repetition," an example in this report would be to not write specifically about every single issue of a given type but rather to select representative samples.
• This is a repeat from the guidelines linked above, but it is critical in any writing: always keep your audience in mind. Make sure the writing will work for them and convey to them, as they read it, the ideas and points you want to communicate. This may require a bit of work to think about what you audience already knows (or doesn’t know!) and how they will understand (or not!) your writing.

The following three presentations are clear, concise resources that give additional tips for writing good technical reports. You do not need to follow every suggestion exactly, but most of these will be valuable and applicable in most technical writing. In the last presentation (the one from RPI), pay attention to the notes on slides 12 through 14 discussing when certain pieces of the example outline are not needed, can be combined with others, etc. In the case of this report, the length is short enough that many of those are not needed as completely separate sections.

1. HATS: A Design Procedure for Routine Business Documents
2. Reports, Proposals, and Technical Papers
3. How To Write a Good Technical Report

[The first two resources are from the Purdue Online Writing Lab, which is an excellent resource for learning about all aspects of all types of writing. It’s well worth a browse or a quick search every now and then!]

Submission Details

• The report should be double-spaced.
• Make a separate title page; this is common for technical reports.
• With figures, code snippets, etc., the report may end up being rather long in page count. As a minimal guideline for length, aim for at least 1500 words total. That may not be sufficient to fully assess your website, though, so it is fine if it is longer. (At the same time, again, avoid any redundant repetition of points.)
• Please submit your reports to dgeorge@iwu.edu.

Rubric

The report will be graded on the following items:

• Writing mechanics (spelling, grammar, sentence construction, etc.)
• Organization (logical ordering of topics, helpful intro/conclusion, clear flow of the writing into / out of each topic.)
• Technical content (is the assessment complete, correct, and accurately explained.)
• Clarity of explanations (remember, your audience is leadership and developers who know nothing about accessibility!)
• Presentation (are text, figures, and code all presented cleanly, with good layout, appropriate fonts and formatting (e.g., use a monospaced font for code; ideally have the code syntax highlighted), clear captions for figures, etc.)
• Completeness of the website assessment (does it fully assess a range of page types on the website.)

Remember: you will be expected to follow the Technical Report Guidelines and Suggestions.

Learning Goals

• Gain a deeper understanding of HTML, CSS, and the construction of websites.
• Build your knowledge and understanding of accessibility issues on the web.
• Introduce you to technical writing as a genre.
• Improve your writing skills overall.