DEV Community: Bianca Aspin

What I've Coded This Week (Week 3—WWCode '100 Days of Code' Challenge)

Bianca Aspin — Wed, 14 Feb 2024 19:44:08 +0000

Cover Image: Confused emoji wondering why the calendar arrows show up on the mobile view (left) of my React Native app but are missing on the web view (right).

This week ended up being pretty frontend heavy, so while I didn't get anything done in Python land, I did spend a lot of time with JavaScript and CSS, with some more React Native troubleshooting (a recurring theme so far in these posts) thrown in.

Quick Links

React Native—The Case of the Missing Arrows in 'React Native Calendars'
JavaScript—JavaScript30 Project #3: CSS Variables
JavaScript—JavaScript30 Project #4: Array Cardio (Day 1)
Responsive Design—Kevin Powell's 'Conquering Responsive Layouts' (Week 1)

React Native—The Case of the Missing Arrows in React Native Calendars

In my last update, I mentioned that I would be working with the 'React Native Calendars' library to build out a calendar tracker for the 'random acts of kindness' app my friend and I are working on. Little did I know that, without even doing anything to modify the default <Calendar> component, I would already have debugging to do. The forward and back arrows to change months were displayed on the mobile view but not the web view.

I found a stale GitHub issue about the missing arrows and saw that another user had success unearthing the arrows by modifying the arrow's height and width within the component's theme (the working theory being that, because there was no height or width explicitly set for the images, they weren't rendering), so I tried this for myself:

import { View } from 'react-native';
import { Calendar } from 'react-native-calendars';

function CalendarView() {

    return (
        <View>
            <Calendar 
                theme={{
                    arrowHeight: 50,
                    arrowWidth: 50
                }}
            />
        </View>
    )
}

The result looked oddly blurry.

Upon inspecting the page to figure out why that might be, I found out that the arrow icons are PNG files. This is what the original image looks like (you may want to get out your magnifying glass!):

To get around this, I took the suggestion of another user in the issue thread to create custom <Arrow> components, utilizing SVG icons from the React Native Vector Icons library.

import { View } from 'react-native';
import { Calendar } from 'react-native-calendars';
import Icon from 'react-native-vector-icons/MaterialIcons'

function CalendarView() {

    const leftArrow = <Icon 
        name="keyboard-arrow-left"
        size={30}
        color='#62BEC1'
    />

    const rightArrow = <Icon
        name="keyboard-arrow-right"
        size={30}
        color='#62BEC1'
    />

    return (
        <View>
            <Calendar 
                renderArrow={(direction) => {if (direction == "left") return leftArrow;
                                if (direction == "right") return rightArrow;  
                            }}
            />
        </View>
    )
}

Unlike PNG files, SVG files can be resized without losing resolution, which we need here. (Check out this helpful comparison of PNG vs. SVG from Adobe for more info.)

Here's what the calendar looks like now:

That's more like it! Next up with this project, I'll be doing more styling and customizations and working out some logic to keep track of the days users complete an act of kindness.

JavaScript—JavaScript30 Project #3: CSS Variables

The third project in Wes Bos's JavaScript30 course was an intriguing exercise that introduced me to a concept I was as yet unfamiliar with: CSS variables, also known as custom properties.

These handy variables allow you to update multiple properties simultaneously with JavaScript. Unlike the variables in the Sass library that Wes briefly mentioned in the lesson intro, which are defined when a page is compiled, regular CSS variables can dynamically update as a user interacts with the page.

Before learning about CSS variables, here is how I would have written the CSS to match the color of some text with the background behind an image on the same page.

.hl {
    color: #ffc600;
}

img {
    background: #ffc600;
}

Then, if I wanted to change that CSS based on the value chosen from the color input selector on the page, I would need to update both the text and the background separately with JS. I'd need to select each element that needs to be updated, as well as the input, from the DOM, and attach an event listener to the input to watch for changes to the color selection and trigger a handler function. The handler would update the text color and background separately.

const text = document.querySelector('.hl')
const image = document.querySelector('img')

const input = document.getElementById('base')
input.addEventListener("input", (e) => handleColor(e))

function handleColor(e) {
    text.style.color = e.target.value
    image.style.background = e.target.value
}

While this isn't so bad with just two elements being updated, it grows in repetitiveness as more elements need to be changed at once.

With CSS variables, we can pull that common value out by defining a variable for it in the root of the document (set to the default value) and then pointing to that variable next to each of the elements sharing it using var(--variable).

  :root {
    --color: #ffc600;
  }

  .hl {
    color: var(--color);
  }

  img {
    padding: 10px;
    background: var(--color);
  }

Now, instead of using JavaScript to change the value for each element individually, we just need it to update the root value. Then, elements referencing that value will also be updated.

const input = document.getElementById('base')
input.addEventListener("input", (e) => handleColor(e))

function handleColor(e) {
    document.body.style.setProperty('--color', e.target.value)
}

Simplifying this code makes it much easier to create one master event handler for updating numerous elements on the page based on various user interactions, as I eventually did for this exercise. The id in this case refers to the input element ('spacing', 'blur', and 'base'), which, if named similarly to the variables, makes selecting the correct value to update simple with string interpolation.

function handleChange(e) {
    id = e.target.id
    value = e.target.value
    if (id === "base") {
        document.body.style.setProperty(`--${id}`, value)
    } else {
        document.body.style.setProperty(`--${id}`, `${value}px`)
    }
}

You can check out the code and finished product for Project #3 on GitHub.

A Note on the 'Input' Event

I used the input event when setting my event listeners. I was initially confused by Wes's approach of adding separate event listeners for mousemove and change events on the page inputs. Looking closely at the MDN reference for "input", though, I realized that the input event type is a new addition as of March 2023. Because it's new, someone using an older device or browser version may have issues getting the page to work as intended.

JavaScript—JavaScript30 Project #4: Array Cardio (Day 1)

This project was, as promised by the title, a great workout and refresher on the various array methods, including .filter(), .map(), .sort(), and .reduce().

These exercises were an excellent opportunity for me to go back and review what gets returned by each of these methods.

.filter(): returns a shallow copy of the original array containing the filtered values.
.map(): returns a new array containing the 'mapped' elements of the original array.
.sort(): returns the same array, sorted in place.
.reduce(): returns the accumulated/aggregated value resulting from iterating through the array (the format of which will vary depending on how you've configured it; one of the reduce exercises here returned an integer value; the other one an object with the tallied appearances of each 'key' element in the original array).

The only one of these methods I haven't used somewhere before was reduce(), and at first, I was a little intimidated. However, I could quickly see its benefits once I took the time to slow down and understand how it works.

Here is how I would have written out Question 4 () before learning about .reduce():

// Array.prototype.reduce()
// 4. How many years did all the inventors live all together?
function totalLifespan(inventorArray) {
    let totalLifespan = 0
    for (let inventor of inventorArray) {
        totalLifespan += (inventor.passed - inventor.year)
    }
    return totalLifespan
}
const totalYears = totalLifespan(inventors)
console.log("Question 4:", totalYears)

With .reduce(), I was able to streamline this code quite a bit! I created a callback function, lifespan, that would return the running total plus the current inventor's lifespan, passing that down the line until we reach the end of the 'inventors' array.

function lifespan(total, inventor){
    return total + (inventor.passed - inventor.year)
}
const totalYears = inventors.reduce(lifespan, 0)
console.log("Question 4:", totalYears)

You could even write that callback inline using an arrow function.

const totalYears = inventors.reduce((total, inventor) => {
    return total + (inventor.passed - inventor.year)
}, 0)
console.log("Question 4:", totalYears)

You can check out the code and finished product for Project #4 on GitHub.

Responsive Design—Kevin Powell's 'Conquering Responsive Layouts' (Week 1)

This past week, I started working through Kevin Powell's 'Conquering Responsive Layouts' course. I'm coming in with some basic familiarity with what it means for a website to be responsive. For instance, I know that adaptable formatting and predictable behavior between devices are vital for accessibility. Kevin's YouTube channel has managed to get me out of multiple CSS jams before, so I figured that this (totally free!) course would be enlightening. One week in, I've already learned a lot.

This first week, we reviewed a few foundational concepts for responsive layouts. During the first lesson, Kevin reiterated a point I'd seen him make in another video ('5 simple tips to making responsive layouts the easy way') that I watched last year while taking some initial steps to make my 'Accessible Parks' app more responsive: HTML is, by default, responsive. The decisions we make with CSS rules we add on top of that HTML are what make it unresponsive. There are two big offenders here in particular:

Fixed widths: Setting the width property in pixels makes it challenging to account for the wide variety of screen sizes that your layout might appear on and sets you up for having to create media queries that still won't be able to perfectly match the behavior you want. Setting width with percentages instead will remove that guesswork.
- max-width: To account for larger screens where you don't want your layout to stretch too far, you can set the max-width property using pixels.
  - This is helpful because, it turns out, people have a hard time reading long, continuous lines of text stretching from one end of a big screen to the other; it makes it harder to keep track of where we are, and we don't want to have to move our heads to keep reading! This article from the Baymard Institute gives a little more background on line lengths and readability: Readability: The Optimal Line Length
Heights: It's better to avoid assigning a height property and let the width and the content within the element determine the height of the container. That way, you won't run into situations where the text overflows or gets truncated. You can still add more height using padding.

Over the next week, we'll dive into another area I've worked with before and am excited to gain better mastery of: Flexbox!

Looking Ahead

That's a wrap for this week!

Here's what I'll be working on until my next post:

Week 2 of Kevin Powell's Responsive Design Course
Working through part of Colt Steele's JavaScript Pro: Mastering Advanced Concepts and Techniques
Another project from JavaScript30
More React Native Calendars (styling and customization)

What I've Coded This Week (Week 2—WWCode '100 Days of Code' Challenge)

Bianca Aspin — Fri, 26 Jan 2024 18:59:04 +0000

(Cover Image: The clock I created for the second project in the 'JavaScript30' course)

It's time for a recap of last week!

What I've Worked On This Week

Quick Links

JavaScript—JavaScript30 Project #2: JS and CSS Clock
Python—Adventures with Unit Testing
React Native—Patching Packages

JavaScript—JavaScript30 Project #2: JS and CSS Clock

I completed the second project in Wes Bos's JavaScript30 course: a clock! This exercise was an interesting challenge that gave me more experience with CSS animations (transformations and transitions), working with dates in JavaScript, and the setInterval function.

I have to admit, I spent a lot of time staring at this clock, watching the minutes tick away (for debugging... but also to admire the cubic bezier timing function that mimics the movement of physical clock hands). I thought my clock looked nice and functional as is. I hadn't even considered the possibility of adding any animation to it, but seeing the pizzazz the realistic recoil of the second hand added made me want to give it a try.

JS30 Project 2: Clock Ticking - YouTube

youtube.com

The tricky part was figuring out how to remedy the blip that occurred when a hand finished a complete rotation; it went back around to reset to its original position and then jumped back to where it was supposed to be.

JS30 Project 2: Visual Glitch - YouTube

youtube.com

In his lesson, Wes said that one way to resolve this issue would be to briefly remove the transition property when the second hand reaches 12:00. However, I later found out that when I disabled transition, the transition-timing-function wouldn't come back automatically, so I added additional logic to my code to get that working again.

const hands = [hourHand, minuteHand, secondHand]

if (secondDegrees === 90) {
    for (let hand of hands) hand.style.transition = "0s"
} else {
    for (let hand of hands) {
    hand.style.transition = "all 0.05s"
    hand.style.transitionTimingFunction = "cubic-bezier(0.1, 2.7, 0.58, 1)"
    }
}

You can see the clock, the code, and a more detailed explanation on my GitHub.

Python—Adventures with Unit Testing

I've been continuing to work through the daily challenges in the WWCode Python Track and using them to get more practice with writing unit tests with Pytest. I learned a valuable lesson this week.

With the way I've been testing for exception handling in the challenges recently, my test would pass even before I'd written the corresponding code because a general TypeError was returned when the code failed.

def odd_or_even(integer):
    if integer % 2 == 0:
        return "Even"
    else:
        return "Odd"

def test_error():
    """Given an invalid input, return a TypeError."""
    string = "banana"
    with pytest.raises(TypeError):
        odd_or_even(string)

The test passed, but when I ran the code myself using a string as an input, this was the message I received:

TypeError: not all arguments converted during string formatting

This message is problematic because it doesn't provide users with a clear reason why the code failed. I wanted to clarify what needs to change with the message, "Input must be an integer."

I did some research and found a very helpful resource (aside from the Pytest docs) that I will be reviewing in more detail as I continue building my unit testing skills: Pytest with Eric, in particular the post, "How To Test Python Exception Handling Using Pytest Assert (A Simple Guide)", which provided several examples of how to check for specific exceptions and messages.

From reviewing Eric's tutorial, I determined that in addition to the code I wrote above, I would need to capture the exception output in an object, excinfo (you could alias this object as anything you want, but this is how it is done in the official Pytest docs, too). That object has an attribute, value, which contains the error message. We'll convert that to a string to check against our desired message.

def test_error():
    """Given an invalid input, return a specific TypeError."""
    string = "banana"
    with pytest.raises(TypeError) as excinfo:
        odd_or_even(string)
    assert str(excinfo.value) == "Input must be an integer."

Now our test fails:

AssertionError: assert 'not all argu...ng formatting' == 'Input must be an integer.'

E - Input must be an integer.

E + not all arguments converted during string formatting

And now, we can modify the code to get that test to pass:

def odd_or_even(integer):
    if type(integer) is not int:
        raise TypeError("Input must be an integer.")
    if integer % 2 == 0:
        return "Even"
    else:
    return "Odd"

React Native—Patching Packages

Following up from last week's post, where my friend and I were grappling with an issue with 'React Native Reanimated', the same errors came back to haunt us again this week. I forgot that, in addition to updating the plugins in the Babel.config.js file (which I discussed last week), there was also a change that we'd made within the 'React Native Reanimated' node package during the troubleshooting process that also contributed to resolving that issue (thanks to this GitHub issue).

But that could never be more than a temporary fix because:

Whenever we next added more packages and ran npm install, that tweak would get overwritten.
Because the node_modules directory is ignored by version control, anyone else installing the packages and running the code on their machine would encounter the same issue.

That's when another GitHub issue led me to the solution: the patch-package library. Here's how I used patch-package to fix this issue.

I followed the instructions to install the library and updated "scripts" in package.json to run patch-package after each install.

"scripts": {
    "postinstall": "patch-package"
 }

I went into node_modules/react-native-reanimated/lib/module/index.web.js and updated the export default from export { _default as default }; to export default _default; as the GitHub issue conversation suggested.
I ran npx patch-package react-native-reanimated.
This generated a new directory, patches, with a patch file containing the diff for the package, that gets accessed with each npm install.

With this issue now put back to bed, I'm looking forward to doing a deep dive into React Native Calendars over this next week.

Looking Ahead

That's a wrap for this week!

Here's what's in the works ahead of next week:

Continuing to explore React Native Calendars
Continuing JavaScript30 and Python Daily Challenges
Starting Kevin Powell's Responsive Design Course

I'll check in again next week to let you know how it all goes—stay tuned!

What I've Coded This Week (Week 1—WWCode '100 Days of Code' Challenge)

Bianca Aspin — Tue, 16 Jan 2024 03:22:37 +0000

(Cover Image: The 'drum kit' I created for the first project in the 'JavaScript30' course)

I'm thrilled to participate in Women Who Code's '100 Days of Code Challenge'. I've wanted to get more involved with Women Who Code for a while now (I've attended a few workshops in the past, which have all been wonderful), and so far, this challenge has been a great way to connect with a fantastic community while getting some much-needed practice with a) consistently coding every day and b) talking about what I'm working on (which I'll put into practice here now!).

I picked up much of what I've learned so far about programming over 15 weeks in Flatiron School's Full-Stack Software Engineering bootcamp (which I started a year ago, a fact that boggles my mind). I learned a lot very quickly, but because of the fast pace of the program, there wasn't much time for me to reflect and go deeper to make sure I really understood the fundamentals. Remedying that will be my main area of focus over the next 100 days.

What I've Worked On This Week

Quick Links

JavaScript—JavaScript30 Project #1: Drum Kit
Python—GMail Web Scraping Tool
Python—'Days of Code' Challenge
Linux Command Line—OverTheWire's 'Bandit'
React Native—Random Acts of Kindness App

JavaScript—JavaScript30 Project #1: Drum Kit

The WWCode Front End track is working through Wes Bos's free 'JavaScript30' course, which aims to strengthen programmers' vanilla JavaScript skills through 30 projects. I spent time last week tackling the first project in the course, a JavaScript drum kit!

This was an entertaining exercise that got me reacquainted with event listeners and query selectors in JavaScript and introduced me to working with embedded audio. I've provided a detailed explanation of the approach I took to solve this exercise alongside my code on GitHub.

As a bonus exercise, I also added functionality for playing the sounds and animations when the on-screen buttons are clicked (as opposed to pressed on the keyboard). The biggest challenge with the click event was figuring out how to grab the parent .key <div> even when one of its children (<kbd>, <span>) got clicked. I added some logic to check whether event.target was one of the child nodes and grab the parentElement value instead.

I'll be coming back to this project because another feature I'd like to add some time in the future is a built-in metronome (every musician's friend)!

Python

GMail Web Scraping Tool

I've been on the post-bootcamp job search for several months now. One thing that would make my life ever-so-slightly easier is if there was a way to compile all the job leads I get emailed from LinkedIn and Indeed together in one place that is not my email (competing for attention among all the spammy promotional emails that crowd into my inbox all day, every day).

I figured I could:

set up filters to forward job alert emails into one folder
write an automation that extracts relevant information (i.e., job title, location, link to posting) from the body of each email
deposit those results into a lovely, distraction-free spreadsheet (I <3 spreadsheets)

Perhaps there are services already established that could do something like this in my GMail inbox (for a fee), but I've wanted to get some experience with web scraping, automation, and Google's APIs, so I figured, "Why not build something myself for fun?" (It's definitely not a way to procrastinate on sending out more job applications.)

I'll probably expand more on this project in a future blog post, but so far, here are some new things I've learned:

Google has documentation and 'getting started' resources for the GMail API, but the sample script implemented in their 'Python Quickstart' guide is using syntax that is documented separately in the Google API Python Client docs and GMail API docs.
Email messages are stored as binary data (base64) and need to be decoded into a human-readable format (ASCII) before we can parse them with web-scraping libraries like BeautifulSoup. Python has a built-in base64 library for this purpose.
Messages have multiple parts arranged in a tree (similar to the DOM in the browser), and these parts have different formats (one branch is for plain text; another is for HTML; there are others associated with various attachment types). I need to do more reading into Multipurpose Internet Mail Extensions (MIME) for a better understanding of how this works.

Other than that, I've done a lot of debugging with ipdb to zero in on key HTML structures in each email that I could incorporate into a scraping script.

'Days of Code' Python Challenge

I've also been participating in the WWCode Python track's ongoing Python 'Days of Code' challenge, with a new prompt posted daily. I've been posting code and commentary on the approach I took and what I learned along the way in this GitHub repository: WWCode-Python-DaysOfCode-2024

Beyond solving the challenges at a basic level and then adapting my code to various use cases and edge cases, I've also been using this challenge as an opportunity to get some practice with writing unit tests (using Pytest), applying concepts I learned in the Introduction to Test and Behavior Driven Development course I took last year.

Something that has struck me throughout this first week of challenges is how a seemingly straightforward task can quickly become more complex once you start thinking about other ways people might use the program or the errors that could arise.

For example, the day four prompt, Write a program to find the sum of all elements in a list, was relatively straightforward to implement, assuming a smaller list comprised only of integers, but once floats (decimals) were added to the mix, things became much more complicated because the anticipated result (0.6) was not what Python returned (0.6000000000000001). This led me down a rabbit hole to figure out what was happening, which turned up this tutorial from the Python documentation, Floating Point Arithmetic: Issues and Limitations. This is a nuance related to how computers represent floating-point numbers. As humans, we typically calculate decimal fractions using base 10 notation, but computers calculate using base 2 (binary). If you're curious about what the difference is between the two, this tutorial on Binary Representation from University of California, Berkeley provides a good primer.

To cut a long story short, the nice, relatively short value we're used to seeing when calculating decimals is often being rounded, but the value stored in memory is often many decimal places longer. To resolve this, I updated the code to return a manually rounded result, adding an optional parameter to specify how many decimal places to round to (which defaults to 2).

Linux Command Line—OverTheWire's 'Bandit'

I'm a Mac user, and macOS is a UNIX-based system, so working from the terminal has already given me experience with some of the most common commands (primarily cd, ls, touch, and mkdir). However, now that I'm working more with Linux and Ubuntu to maintain a cloud-based server for ongoing projects, I'm realizing I've still got a lot to learn to harness the full power of the command line.

When talking with a friend about this learning curve, he recommended I check out the "wargames" offered by the OverTheWire community, starting with a game called "Bandit"., which is the entry point for "absolute beginners" to get acquainted with the basic concepts needed to play other games in the collection. I'm currently on Level 7 of 34, and it's been a fun challenge so far that has me feeling like a secret agent.

I don't want to give too much away because a core part of the experience is figuring out what to do with limited background information (other than a list of commands you may or may not need to solve each level). Some things I've learned so far (which may or may not have been used in the course of the game):

The Linux man-pages project is an incredible resource.
cat is not a command to summon a feline friend (drat!), but it can print file contents in your terminal (among many other things; see Geeks4Geeks' cat Command article for examples).
find is a potent tool for searching for files in a directory, with a wide variety of criteria you can specify to narrow your search (see Geeks4Geeks' Find Command article for examples).

React Native—'Random Acts of Kindness' App

In addition to the above activities, which have helped me strengthen fundamentals I picked up during my coding bootcamp, I've also been collaborating with a friend to build a 'random acts of kindness' app to practice a new framework for both of us, React Native. Having focused primarily on web development over the last year, this first foray into mobile programming has definitely been a learning experience. However, the nice thing about having a React background already is that a lot of the concepts and syntax we've encountered so far with React Native are very similar.

This week, we spent some time troubleshooting why we were getting errors when using React Navigation "drawers" (which allow you to have a navigation menu that opens from the side of your screen, like a drawer). The message is similar to the one below:

ERROR in ./node_modules/@react-navigation/drawer/lib/module/views/legacy/Drawer.js 84:25-39

export 'default'.'Value' (imported as 'Animated') was not found in 'react-native-reanimated' (possible exports: FlatList, Image, ScrollView, Text, View, addWhitelistedNativeProps, addWhitelistedUIProps, createAnimatedComponent

Upon further investigation, we found out from a closer review of the React Navigation Drawer Navigator docs that, in order to use the latest version of the 'React Native Reanimated' dependency, it needs to be configured a certain way, as described in its installation guide. In the end, all we needed to do in addition to installing the requisite packages was add the React Native Reanimated plugin to our Babel configuration file.

module.exports = {  
presets: [  
],  
plugins: [  
'react-native-reanimated/plugin',  
],  
};

Looking Ahead

That's a wrap for this week. For the upcoming week, I'm planning to work more with:

Continuing the JavaScript30 course
Building out my 'Job Alert Scraper' tool
Continuing to solve the daily Python code challenges
Finishing up the OverTheWire 'Bandit' game
Experimenting with React Native calendar views

I'll check in again next week to let you know how it all goes—stay tuned!

Code-Along: Implementing 'Search By Criteria' Functionality with React, Formik, and Flask-SQLAlchemy

Bianca Aspin — Wed, 12 Apr 2023 20:44:29 +0000

My Current Project

As I reach the end of my journey as a bootcamp student, for my capstone project, I'm building an app that will allow users to search for national parks with particular accessibility-related amenities available. For today's blog, I wanted to walk through how I implemented a central piece of functionality for the app: the search. More specifically, the ability to search using multiple criteria.

The Problem I'm Trying to Solve

The search was at the heart of why I had the idea to create this app in the first place. In the official National Park Service mobile app, a user can search for parks to explore based on:

their proximity to the park
the name of the park
the state the park is located in
activities available at the park
topics discussed at the park
the type of park (e.g., park, monument, recreation area)

That's a lot of search options! However, despite there being a wide range of accessible offerings at the parks, there currently isn't an easy way for users to find parks based on the accessibility offerings available. A user has to click into each park, navigate to the amenities section, and from there, find the relevant section on accessibility.

The National Park Service website provides a map of accessibility in the national parks, showing the location of all parks in the United States with accessible features and services. However, clicking on each location only provides a link to the park's accessibility page. There's no way to see at a glance which amenities are available.

There's no way to know whether "accessibility" at a given park means having wheelchair-accessible trails, having a sign-language interpreter for guided tours, or having tactile exhibits for those with visual impairments. The user has to manually search each page to whittle down which ones have the amenities they need to make the most of their trip, which is needlessly time-consuming.

My Vision for the Search Function

When I first sketched out what I wanted the user interface to look like, I knew I wanted the homepage to be a list of the various accessibility and accessibility-adjacent (e.g., cellular signal, access to groceries, access to drinking water) amenities available at the parks. I wanted users to be able to select (by clicking the corresponding checkbox) any of the criteria that would help them decide where to go, click 'Search,' and have a list of parks returned to them matching all the criteria they selected.

Let's code along together to make that vision a reality!

Create 'Search' and 'Results' Components

We'll start by creating two components to house the search and results, respectively, and importing those into our main app to add them to the component tree. At the same time, let's add some basic routing by importing Switch and Route from React Router. (Note: I'm using version 5 of React Router here.)

// App.js

// React Imports
import { React } from 'react';
import { Switch, Route } from 'react-router-dom';

// Component Imports
// Note: This import reference will vary based on your file structure. In this case, the main App is stored outside the 'Components' folder.
import { Search } from './Components/Search';
import { Results } from './Components/Results';

function App() {

    return (
    <Switch>
        <Route path='/search'>
            <Search />
        </Route>
        <Route path='/results'>
            <Results />
        </Route>
    </Switch>
    )
};

export default App;

Create the Initial Form

Next, in the search component, let's import React's useState and useEffect hooks. We'll put those to work right away, fetching the amenity data from the server from within useEffect with an empty dependency array so that the GET request only gets sent when the component initially renders, not continuously. Once that data is successfully retrieved, we'll save this array of amenity objects as a state variable.

With the amenities array saved in state, we can then iterate through using the map() method. Cycling through each amenity object in the array, we'll map its properties onto the attributes of an <input> element. The end result of the map will be a new array of checkbox elements that can then be added within the overall <form> being returned by the Search component.

Here's what the user interface should look like so far (without adding styling, for simplicity):

Here's what the code should look like so far:

// Search.js

// Importing React hooks
import { useState, useEffect } from 'react';

function Search() {

    // Setting state for amenities
    const [amenities, setAmenities] = useState([])

    // Fetching amenities from within useEffect
    useEffect( () => {
        fetch('/amenities')
            .then(response => response.json())
            .then(amenityData => setAmenities(amenityData))
    }, [])

    // Iterating through amenities to create an array 'checkbox' input elements.
    const checkboxes = amenities.map( (amenity) => {
        return (
            <div key={amenity.id}>
            <label>
                <input
                    type="checkbox"
                    name="checked"
                    value={amenity.id}
                />
                {amenity.name}
            </label>
            <br />
            </div>
        )
    })

    return (
        <div>
            <h1>Search</h1>
            <form>
                // Inserting that array of checkboxes into the form.
                {checkboxes}
                <input type="submit" value="Search" />
            </form>
        </div>
        )
    };

export default Search;

One thing that you'll notice looking at the code above is that each of the checkbox elements has the same name, "checked". This is by design, as we'll cover in the next section.

Configure Formik

Formik is an incredibly useful React library for managing state within our forms. Setting up the useFormik hook and using its built-in state and change handlers takes out a lot of the work that comes with setting up form fields as controlled components.

// Search.js

// Other React imports

// Importing Formik
import { useFormik } from 'formik';

function Search() {

    // State-setting, useEffect fetching, etc.

    // Initializing the useFormik hook
    const formik = useFormik({
        initialValues: {
            checked: []
        },
        onSubmit: (values) => {
            console.log(values)
        }
    })

    // checkboxes, return, etc.
};

In the snippet of code above, we're initializing the useFormik hook. We're only specifiying one field here, 'checked' — corresponding with the name attribute that we assigned to each of the checkbox elements earlier — and setting it equal to an empty array for its initial value. Per Formik's documentation on forms with checkbox groups, "given that the fields all share the same name, Formik will automagically bind them to a single array". Anytime we click on a checkbox, that checkbox's value (which we've set to the amenity's unique ID) gets added to that array. If we click on the same box again to uncheck it, that value gets removed from the array.

Of course, to accomplish that, let's not forget that Formik's handlers need to get added on to the form elements. The formik.handleChange prop should get passed in to each input's onChange attribute:

// Search.js

// imports

function Search() {

    // State-setting, useEffect fetching, Formik set-up, etc.

    const checkboxes = amenities.map( (amenity) => {
        return (
            <div key={amenity.id}>
                <label>
                    <input
                        type="checkbox"
                        name="checked"
                        value={amenity.id}
                        // Adding Formik's built-in onChange handler.
                        onChange={formik.handleChange}
                    />
                    {amenity.name}
                </label>
                <br />
            </div>
        )
    });

    // Return, etc.
};

The formik.handleSubmit prop should get added to the overall form's onSubmit attribute:

// Search.js

// imports 

function Search() {
    // State-setting, useEffect fetching, Formik set-up, etc.
    // Checkboxes

    return (
        <div>
            <h1>Search</h1>
            <form onSubmit={formik.handleSubmit}>
                {checkboxes}
                <input type="submit" value="Search" />
            </form>
        </div>
    )
};

Now, let's hop back to our useFormik hook and take a closer look at onSubmit. Formik initially receives an array of strings from the form. We're going to want to take those individual strings and join them together into one string, which we can accomplish using the join() method.

Here's what that updated code should look like now:

// Search.js

// imports

function Search() {

    // State-setting, useEffect fetching

    const formik = useFormik({
        initialValues: {
            checked: []
        },
        onSubmit: (values) => {
            const value_array = values['checked'];
            console.log('Value Array:', value_array)
            const value_string = value_array.join();
            console.log('Value String:', value_string)
        }
    })

    // Checkboxes, return, etc.

};

And here's what output should look like when printed in the browser console:

Joining these ids together into one string will make communicating our request to the server much easier, as we'll discuss in the next part.

Before I realized that I could pass this string of multiple ids as a parameter in my fetch request to my server, I tried setting up a series of fetch requests with each individual amenity ID to return arrays of matching park objects and then filtering through those arrays to find the intersecting records. I won't go into the nitty-gritty details here, but suffice it to say that, not getting the expected results 30 lines of code later, there is no straightforward way of accomplishing this kind of filtering with JavaScript. However, utilizing the powerful data manipulation capabilities of Python and SQL, this task is much simpler to accomplish on the backend!

Backend

The backend of this project uses Python, Flask, and SQLAlchemy. (Note: I won't get into the details of the initial configuration of those libraries but encourage you to check out the Flask and Flask-SQLAlchemy docs for more background.)

Create API Resource and Route

To build out the route that we'll use to return search results, we'll start by creating a new API resource, 'ParksByAmenityIds', with a GET method that takes a string of ids as a parameter (hey, that sounds like what we just made on the frontend!). Before building out the logic within that resource, let's immediately go ahead and add this resource and the corresponding endpoint below (it is very easy to forget otherwise!).

# app.py

from flask import make_response
from flask_restful import Resource
from config import app, api
from models import Amenity

class ParksByAmenityIds(Resource):
    def get(self, id_string):
        pass

api.add_resource(ParksByAmenityIds, '/park_amenities/<string:id_string>')

With that out of the way, let's build out the underlying logic.

Build Out Query Logic

First, we'll split the id_string into an array of separate ids.

id_array = id_string.split(',')

Next, we'll use a list comprehension to convert those id elements from strings into integers.

int_ids = [int(id) for id in id_array]

Now, we can get a list of the parks that have any (but not all) of the specified amenities by querying the ParkAmenity join table. We can use the .in_ column operator (which operates similarly to Python's in keyword) to return all the parks with a matching amenity id. (For the example I used with amenity ids 1, 2, and 3, there were 276 items returned with duplicates.)

all_matching_amenities = [amenity.to_dict() for amenity in ParkAmenity.query.filter(ParkAmenity.amenity_id.in_(int_ids)).all()]

Next, we'll use another list comprehension to create a new list of all the park IDs from the result of the all_matching_amenities query.

all_park_ids = [element['park']['id'] for element in all_matching_amenities]

Using yet another list comprehension, let's return all of the ids which appear in the park ID list as many times as there are amenities we're searching for (in this case, we've got a list of three amenities). We're using the .count() method as well as finding the length of our amenities list with len() to make this comparison. The result will be a list of all the park ids connected to all the specified amenities.

multiple_matches = [id for id in all_park_ids if all_park_ids.count(id) == len(int_ids)]

We can quickly remove all of the duplicates by turning that list into a set with Python's set() constructor.

unique_matches = set(multiple_matches)

In this example, we've whittled down 276 items that match at least one criterion to a set of 18 items that match all three criteria — fantastic!

Using those unique matches, we can now query the Parks table (again using the .in_ column operator) to return all the parks with an id appearing in our new set of unique matches. This list of park objects (with all their details, not just the ids) is what our server will send back to the frontend in response to our search request.

parks = [park.to_dict() for park in Park.query.filter(Park.id.in_(unique_matches)).all()]

Add Error Handling if No Matches Found

Before we tie this back together with our frontend, we should add some error handling. It will not be uncommon for users to select a combination of criteria that won't yield any matches. We'll want to let the frontend know if this is the case so that it can render an error message to the user accordingly. In this case, we'll add a clause that specifies that if the length of the list of parks returned is 0, the server should send back an error.


if len(parks) == 0:
    response = make_response(
        {"error": "No matching parks."},
        404
        )
    return response

else:
    response = make_response(
        parks,
        200
        )
    return response

Here's what the entire resource looks like, all put together:

# app.py

# imports, additional resources/routes

class ParksByAmenityIds(Resource):
    def get(self, id_string):
        id_array = id_string.split(',')
        int_ids = [int(id) for id in id_array]

        all_matching_amenities = [amenity.to_dict() for amenity in ParkAmenity.query.filter(ParkAmenity.amenity_id.in_(int_ids)).all()]
        all_park_ids = [element['park']['id'] for element in all_matching_amenities]
        multiple_matches = [id for id in all_park_ids if all_park_ids.count(id) == len(int_ids)]
        unique_matches = set(multiple_matches)

        parks = [park.to_dict() for park in Park.query.filter(Park.id.in_(unique_matches)).all()]

        if len(parks) == 0:
            response = make_response(
                {"error": "No matching parks."},
                404
            )
            return response

        else:
            response = make_response(
                parks,
                200
            )
            return response

api.add_resource(ParksByAmenityIds, '/park_amenities/<string:id_string>')

Tying the Frontend and Backend Together

Now that we've got this route built out, let's update the Formik onSubmit handler with that route to fetch the matching parks from the server. We'll add a clause for rendering an error on the search page if no matches are found. We'll set up searchError as a boolean state variable and have the error message render conditionally based on whether the error state is true.

// Search.js

// imports

function Search() {

    const [amenities, setAmenities] = useState([])
    const [searchError, setSearchError] = useState(false)

    // useEffect fetching

    const formik = useFormik({
        initialValues: {
            checked: []
        },
        onSubmit: (values) => {
            const value_array = values['checked'];
            const value_string = value_array.join();
            fetch(`/park_amenities/${value_string}`)
                .then(response => {
                    if (response.ok) {
                        response.json()
                        .then(parkData => console.log(parkData))
                    } else {
                        response.json()
                        .then(error => setSearchError(true))
                    }
                })
        }
    })

    // Checkboxes

    return (
        <div>
            <h1>Search</h1>
            {searchError
                ? <p>No matches found.</p>
                : null
            }
            <form onSubmit={formik.handleSubmit}>
                {checkboxes}
                <input type="submit" value="Search" />
            </form>
        </div>
    )
};

To be able to render those matches in our 'Results' component, we'll need to establish parks as a state variable in the parent component (App) and pass those down to Search and Results as props.

// App.js

// React Imports
import { React, useState } from 'react';

// Additional Imports

function App() {

    const [parks, setParks] = useState([])

    return (
    <Switch>
        <Route path='/search'>
            <Search setParks={setParks}/>
        </Route>
        <Route path='/results'>
            <Results parks={parks}/>
        </Route>
    </Switch>
    )
};

export default App;

Now, upon a successful search, we can use the setParks prop to save those matches in state. We'll also use the useHistory hook from React Router to send us to the Results page upon a successful search using the .push() method.

// Search.js

import { useHistory } from 'react-router-dom';
// Additional Imports

function Search({ setParks }) {
    // state-setting

    const history = useHistory()

    // useEffect fetching

    const formik = useFormik({
        initialValues: {
            checked: []
        },
        onSubmit: (values) => {
            const value_array = values['checked'];
            const value_string = value_array.join();
            fetch(`/park_amenities/${value_string}`)
                .then(response => {
                    if (response.ok) {
                        response.json()
                        .then(parkData => setParks(parkData))
                        .then(() => history.push('/results'))
                    } else {
                        response.json()
                        .then(error => setSearchError(true))
                    }
                })
        }
    })

    // checkboxes, return, etc.
};

Last, let's quickly get a basic Results component built out:

// Results.js

function Results({ parks }) {

    const li_parks = parks.map(park => {
        return <li key={park.id}>{park.name}</li>
    })
    return (
        <div>
            <h1>Results</h1>
            <ul>
                {li_parks}
            </ul>
        </div>
    )
};

export default Results;

And there we have it, a successful search — hopefully the first of many for our users!

An Alt-Text Primer

Bianca Aspin — Thu, 30 Mar 2023 21:13:15 +0000

An Alt-Text Primer

In my post last month about Screen Readers and HTML Accessibility, I touched on some fundamental aspects of how the screen reader navigates the page and makes the web browsing experience more perceivable and operable for users with visual disabilities. I also mentioned that many newcomers to coding first hear about screen readers and accessibility in the context of images—specifically, the alt tag used within <img> HTML elements. As promised, I'm returning to explore that topic in more detail today.

What is Alt-Text?

Alternative text, often shortened to 'alt-text,' is precisely what it sounds like—a text alternative for a non-text element, such as an image or graphic. Mozilla's MDN Web Docs describe that the HTML alt attribute is a container for text describing an image. A screen reader will grab the text in this alt tag and read it in place of the image.

Beyond screen reader accessibility, there are other benefits of the alt tag, too; it's what renders in place of an image that can't load (perhaps due to a bad internet connection or a broken link), and it also factors into the visibility of a website on search engines (Search Engine Optimization, aka SEO).

The MDN Docs state that an alt tag "isn't mandatory but is incredibly useful for accessibility." This is technically true in that omitting the alt tag won't bring a page crashing down like a misplaced comma or forgotten closing tag will. But in practice, if there is one takeaway that you get from this post at all, it's that alt tags should always be included on our images.

What Happens if I Don't Include Alt-Text?

Adding alt tags to images is often considered low-hanging fruit for making a website more accessible, and yet inaccessible images remain one of the most common issues. By not including alt text, we risk depriving our screen reader users of important information and added context that images provide to our sighted users.

There are a couple of different things that a screen reader might do when it encounters an image without an alt tag:

Read the image's src tag (typically the image's URL or filename) in place of the image. If the filename is descriptive of the contents, this could be better than nothing. Often though, this is something like 'IMG_1598.jpg' or a lengthy Google Images link that reads like a jumble of random characters.
Announce "image" or "graphic" and leave it at that. What is contained within the image will remain a mystery to the user—was it a graphic important to their understanding of the surrounding material or a piece of decorative clip art?

You can see and hear an example of how screen readers interpret an image with vs. without an alt tag in the brief example below, which demos two standard screen reader technologies (VoiceOver for Mac and ChromeVox):

For those who want another practical perspective of how alt-text can go wrong, check out accessibility engineer Steffany Newman of Web Accessibility Education's video showing examples of poorly executed alt-text on a popular e-commerce website you may have heard of before:

What Should I Include in my Alt-Text?

Shakespeare's Hamlet might have said that "To be or not to be?" is the question, but that was before the internet came along and web developers, designers, and content creators were faced with the actual ultimate question: what goes inside that alt attribute we've been discussing? The answer is: "it depends." However, there are a few important points to remember that can guide us.

`alt` tags for decorative images should be empty

Our gut reaction to hearing that we should include alt tags on all of our images might be to say, "Okay, I'm going to include alt-text on every. single. image. on my website." However, there's a difference between including an alt tag on every image and including a text description inside each tag.

As it turns out, not every image needs a description. If it's a purely decorative image—that is, it doesn't include any meaningful content, it's only used for layout, and deleting the image wouldn't do anything to impact the understanding of the surrounding text for our sighted users—all we need to include in the alt tag is an empty string (you may also hear this referred to as a null alt attribute). This tells the screen reader that it can ignore the image.

(By KEN111 via the Noun Project, CC-BY 3.0)

<!-- Don't Do This: -->
<img src="pretty_flower_border.jpg" alt="Floral Border">

<!-- Do This: -->
<img src="pretty_flower_border.jpg" alt="">

Adding a text description where it isn't needed will add (literal) noise to the screen reader's readback of the page. Not having any alt tag would cause the same issue, as the screen reader assumes an alt tag should be there and tries to find a substitute. An empty alt tag will prevent both of these pitfalls.

`alt` tags shouldn't include "image of" or "graphic of"

Another thought we might have, being the well-intentioned people we are, might be, "Hey, I should include 'image of' as part of my alt-text so that the user knows what's being read is a description of an image." Kudos for being thoughtful, but doing that would be unnecessary, repetitive, and redundant. Screen readers typically announce 'graphic' or 'image' before reading the alt text.

(By mauser via Wikimedia Commons, CC-BY-SA 3.0)

<!-- Don't Do This: -->
<img src="untitled_goose_puppy.jpg" alt="Image of a Golden Retriever puppy carrying a plush goose toy.">

<!-- Do This: -->
<img src="untitled_goose_puppy.jpg" alt="Golden Retriever puppy carrying a plush goose toy.">

`alt` tags should be brief yet represent the content and function of the image

Even though we may feel compelled to describe every minute detail of the image, or add a little pizzazz or extra tidbits of information into our alt-text, we shouldn't give in to that temptation. Our goal with alt-text is to briefly (in a few words or a sentence, no paragraphs here) summarize the information that a sighted user would glean by looking at the picture. If we still want to add something extra, we can always do that within the body of the text or a caption so that everyone else can enjoy our wit or insight.

On the other hand, we must also be careful to include enough information that a screen reader user gets the same context and value from the image as a sighted user would. We shouldn't just describe the appearance of the image, we also explain what we intend the user to understand based on the image.

(By J.K. Nakata, U.S. Geological Survey via Wikimedia Commons)

<!-- Don't Do This: Too Much/Irrelevant Information -->
<img src="Loma_Prieta_Damage.jpg"
alt="A wood-framed house with an avant-garde split roof and ornate and beautiful wood panel siding and five glass windows across, collapsed onto a blue car following the Loma Prieta earthquake.">

<!-- Also Don't Do This: Too Little Information -->
<img src="Loma_Prieta_Damage.jpg"
alt="A house collapsed onto a carport.">

<!-- Do This: -->
<img src="Loma_Prieta_Damage.jpg"
alt="A wooden house collapsed sideways onto a carport, demonstrating how a lack of shear walls contributed to the failure of the structure.">

Additional Resources

If, like me, you don't do well with the grey area of "there's no one right answer," and you're realizing that alt-text can be a very nuanced and complex topic, fear not! There's a fantastic resource for you to bookmark: An alt Decision Tree. The Web Accessibility Initiative made narrowing down what we need to include as analytical and straightforward as possible with this flowchart. That resource references their in-depth Images Tutorial, where you can explore the topics I introduced here in greater detail and see more examples. I highly recommend checking this out too!

Two Ways to Make Your Command Line Interfaces More Accessible

Bianca Aspin — Wed, 15 Mar 2023 19:57:44 +0000

Introduction

Command Line Interfaces (CLIs) are an essential part of every developer's arsenal of tools, allowing them to perform repetitive tasks with greater speed and efficiency. Basic CLIs are also a typical first project when you're learning Python. They are an excellent way to practice using Python functions, solidify your understanding of control flow concepts like looping and conditional statements, and get experience writing scripts. So whether you're just starting out building your first command line application or developing the next big suite of developer tools, here are a couple of small ways to improve the accessibility of what you build.

The Accessibility of CLIs

CLIs are often considered inherently more accessible for screen reader users than web-based applications. After all, you don't need to worry about alt text for images and reading order when your entire app is text-based and proceeds linearly, and CLIs are already entirely keyboard-operated by nature.

As it turns out, the simplicity of CLIs can be a double-edged sword for accessibility. Without the underlying structure I discussed in my post about HTML accessibility, a screen reader user has to scan through the output line-by-line instead of using its built-in shortcuts to jump to the parts that are most relevant to them. This wouldn't be so bad if the output were only plain and simple text. However, in practice, CLIs often still contain many elements catered toward a sighted audience. These visual elements are distracting and tedious for a screen reader user to navigate.

Research Study

Three Google user-experience researchers, Harini Sampath, Alice Merrick, and Andrew Macvean, published a study in 2021, Accessibility of Command Line Interfaces, exploring the various issues that arise for screen reader users when interacting with CLIs. Based on insights gleaned from screen reader users participating in user interviews and a usability evaluation study, the authors made several recommendations for improving CLI accessibility.

I highly recommend checking out the full article, which is packed with helpful information, including excerpts from interviews with the users themselves. In the following sections, I'll be delving into two of the recommendations made in this article.

Recommendations

Let users bypass visual elements

As developers, we constantly look for ways to improve our users' experience when using our apps. Our natural inclination will be to make what we create visually appealing to our users, and CLIs are no exception. If anything, the straightforward, 'bare bones' appearance of the output rendering in the terminal makes it all the more tempting to throw in an eye-catching element or two to better grab the user's eye.

Without the ability to embed images, where can we turn to accomplish this task? ASCII art. ASCII art is frequently included in CLIs in some form. The purpose for having it varies.

Sometimes, it's there to greet users with a decorative title at the launch of the app.

A screen reader will announce this output as "star star star star star star star star star star star star..."

Sometimes, it mimics a status or progress bar from a graphical user interface (GUI).

A screen reader will announce this output as "full block full block full block light shade light shade light shade...30%"

Sometimes, it's there to format data in the output to look more like a traditional table with grid lines and borders.

A screen reader will announce this output as "box drawings double down and right, box drawings double horizontal, box drawings double horizontal, box drawings double horizontal, box drawings double down and horizontal..."

While this formatting can make CLI output more pleasant for a sighted user to read, it makes it exponentially more unpleasant for a screen reader user to take in. Without the underlying structure of an HTML page, there's no option for the screen reader to skip to the main content. Instead, the user must sit there while every individual symbol and character is read.

Check out the video below for an example of how a screen reader parses through ASCII art. The first 20 seconds should be more than enough to give you an idea of the problems ASCII output can pose for screen reader users.

Fear not, though! You don't need to overhaul your app to remove that ASCII logo you painstakingly hand-coded. We can get around this issue by building some logic at the beginning of the app to check whether the user wants these visual enhancements. Then, we can conditionally render the visual elements based on the user's response to that prompt. Here's one approach:

Open your app with a plain text greeting.
Initialize a variable to hold the user's viewing selection.
Prompt the user to choose their viewing experience (confirm if they would like to view the app in 'plain text mode' or words to that effect, and describe what that means).
Update the 'viewing selection' variable you initialized earlier, and print a confirmation message that the user has opted for plain text mode.
Wrap any purely visual elements like ASCII art, decorative lines, and table formatting in a conditional statement, to render only if 'viewing selection' variable is false.

Here's what this approach looks like in practice:

# imports, database initialization, etc...

# These lists help with data validation throughout the app:
YES = ['y', 'ye', 'yes']
NO = ['n','no']

if __name__ == '__main__':

# Start with a plain text greeting instead of the ASCII art:
print("Welcome to My Totally Epic CLI!")

# Initialize a variable for the user's viewing selection:
plain_text_mode = False

# Prompt user to choose viewing experience:
plain_select = input('''
Would you prefer to use this app in plain text mode
(with visual elements and decorations removed)?
Enter 'Y' for 'Yes,' 'N' for 'No': ''')

# Update the variable you initialized earlier.
# Print a confirmation message that 'plain text mode' is active.
if plain_select.lower() in YES:
    plain_text_mode = True
    print("Plain text mode selected.")

# If 'no' is selected, visual elements you preface with 
# 'if not plain_text_mode' will be displayed: 
if not plain_text_mode:
    print('''
    # Your beautiful ASCII art goes in here!
    ''')

Let users export tables to CSV

Tables were already mentioned in the previous section for how they are formatted in CLI output. However, even without the distracting noise of those extra characters forming the table's borders, tables still pose a problem for screen readers. That lack of any underlying structure is back to cause issues, as the screen reader has no landmarks to anchor itself, like header rows and row boundaries. This means that screen reader users essentially have to pick out how many columns there are, memorize what each column represents, and then try to keep track of which column is being read at any time as they navigate through the table cell-by-cell, line-by-line.

When users in the Google study were asked how their CLI table viewing experience could be improved, they pointed to the ability to export these tables in another format that their screen reader could better navigate, such as a CSV file, as a better experience.

We can use Python's csv module to write data to its own CSV file right from within our CLI application. Once we've imported the csv module, here is how we would go about writing the results of a database query to their own csv file:

Use open() to specify a path for the new file and open it in 'write' mode.
Create a list containing the fields returned by the query.
Create a new instance of the DictWriter class, which converts dictionaries into rows in the csv file.
Use DictWriter's writeheader() method to write the field names from the list to the csv file.
Iterate through the records returned by your query and use DictWriter's writerow() method to write each record to the csv file.
Use close() to finish editing and close the csv file.

Here's what this approach looks like in practice:

# Import the csv module:
import CSV

# Perform your database query:
pets = session.query(Pet).filter(Pet.owner_id == owner_id).all()

# Name the file and open it in 'write' mode:
pets_csv = open("./csv_output/your_pets.csv", mode="w")

# Create a list containing the fields returned by the query.
fields = ["Pet ID", "Name", "Age", "Breed", "Temperament", "Treats", "Notes", "Owner ID"]

# Create an instance of DictWriter:
write_pets = csv.DictWriter(pets_csv, fieldnames=fields)

# Use DictWriter to create a header row in your CSV file:
write_pets.writeheader()

# Iterate through the records returned by the query.
# Use DictWriter to create a row for each of those records:
for pet in pets:
    write_pets.writerow({
       "Pet ID": pet.id,
       "Name": pet.name,
       "Age": pet.age,
       "Breed": pet.breed,
       "Temperament": pet.temperament,
       "Treats": pet.favorite_treats,
       "Notes": pet.notes,
       "Owner ID": pet.owner_id
    })

# Finish editing and close the csv file:
pets_csv.close()

This gets our tabular data into a CSV file, but at this point, the user will still need to locate and open this file. We can save them that step by adding functionality to open that file in their default system viewer once it has been closed. This step gets a bit more complicated, since now we have to work around different operating systems, but thanks to this StackOverflow post about opening files in the system default viewer, we have a way to do it!

We'll need to import Python's os, subprocess, and platform modules to help. What these modules will do in a nutshell:

os allows us to tap into the user's operating system dependent functionality.
subprocess allows us to start a new process on the user's device (opening their spreadsheet software, in this case).
platform provides us with identifying information for the user's platform (Mac, Windows, or Linux).

With those modules imported, here's how we can build out a helper function to check the user's operating system and launch our new csv file in their default app for spreadsheets:


import os, subprocess, platform

def file_opener(filepath):

# MacOS
if platform.system() == 'Darwin':

    subprocess.call(('open', filepath))

# Windows
elif platform.system() == 'Windows':

    os.startfile(filepath)

# Linux
else:
    subprocess.call(('xdg-open', filepath))

With this helper function built out, all we have left to do is call it after we've closed the file.


pets_csv.close()

file_opener("./csv_output/your_pets.csv")

And with that, our data will now open up in the user's spreadsheet software, ready to be read more efficiently by their screen reader!

An Introduction to Screen Readers and HTML Accessibility

Bianca Aspin — Wed, 15 Feb 2023 05:41:54 +0000

What are screen readers, how do they navigate a website, and how can we make our HTML more screen reader-friendly?

Screen Readers and Accessibility

Chances are good you've heard something about screen readers already in your programming journey. It's often mentioned when you're first learning how to embed images into an HTML document, in the context of adding alt tags to images. (I'll explore alt tags more in an upcoming post.) What often isn't discussed is what a screen reader is.

A screen reader is software that lets a blind or visually-impaired user consume information from a computer screen in another format, like audio or braille.

One common misconception is that screen readers are simply text-to-speech software. While synthesized speech is a component of any screen reader, it is only one of several features. A user might not even use this audio feedback. They could connect a refreshable braille display to render the screen reader's output instead. A screen reader is also far more than a "reader"—it's a tool for navigating and using a computer. Screen readers don’t merely repeat the text on the screen, they interpret visual cues—like images, links, buttons, headings, menus, and forms—and allow users to interact with those elements.

Before we get much further, an example of this technology in action would be helpful. Marc Sutton of the University of California San Francisco created an excellent demonstration of how a screen reader navigates a site back in 2016. Take a couple of minutes now to watch this brief demo. (Note: At the end of the video, Marc demonstrates some issues with HTML tables. We won't be discussing those in this post; tables are another topic warranting a post of their own.)

In the video, Marc shows how a screen reader user can use built-in commands to navigate. These shortcuts let users scan a webpage and drill down on areas of interest. Users can jump around to different sections using headings and can also listen to a list of links pulled from the page to find what they're looking for quickly.

A screen reader is a very powerful tool to have at one's disposal. However, it can only perform these handy shortcuts if a page has the proper underlying structure.

Here are three essential areas to consider when building a new HTML document. These steps will help screen reader users easily navigate our page without spending hours reading through our content line-by-line to find what they need.

Steps for Improving Screen Reader Accessibility

Include a Descriptive Page Title

The first step we can take when setting up an accessible HTML document starts at the top: the page's title itself.

The 'title' I'm referring to in this case is the one that displays within your browser's tabs or along the top of the window. It's defined using the <title> tag in the <head> (metadata) section of an HTML document.

<!DOCTYPE html>
<html lang="en">
    <head>
        <link rel="stylesheet" type="text/css" href="style.css">
        <!--This is where you'll define the page title:-->
        <title>Title</title>    
    </head>
    <body>
    </body>
</html>

The title serves an essential purpose for screen reader users. It's the first thing the screen reader announces upon opening a page or switching to that page from a different tab. A sighted user might decide whether to read a page by giving it a quick scan from top to bottom. This kind of scanning takes longer to do with a screen reader. Well-written titles allow screen reader users to identify the general content quickly. From there, they can decide whether to venture further into the page.

First, each <title> within a site should be unique. If we have many pages within one of our sites, they shouldn't all have the same title. Without a way to tell one page apart from another, a screen reader user will have to go further into the page to know its contents, which is time-consuming.

Relatedly, <title> should be front-loaded, putting the most relevant and unique identifying information first. That way, a screen reader user only needs to spend as long as necessary to find out what's on that page.

<!-- Back-Loaded Version (Avoid This) -->
<title>Dunder Mifflin Paper Company | Contact Us</title>

<!-- Front-Loaded Version (Do This) -->
<title>Contact Us | Dunder Mifflin Paper Company </title>

This practice also helps sighted users distinguish one page from the other if they have many tabs from your site open at once.

While we strive to make each <title> unique and descriptive, we should also keep them brief. A good rule of thumb is to keep the length of a title under 60 characters.

<!--Longer Version - 124 Characters (Avoid This) -->
<title>Michael Scott's Dunder Mifflin Scranton Meredith Palmer Memorial Celebrity Rabies Awareness Pro-Am Fun Run Race For the Cure</title>

<!--Shorter Version -- 51 Characters (Do This) -->
<title>Charity Race for the Cure | Dunder Mifflin</title>

Provide a Meaningful Hierarchy with Headings

A screen reader user listens to our descriptive page title and decides they want to explore it in more detail. Their next step might be to skim the page for a high-level view of what's there. They can do this by jumping between any heading tags (<h1> through <h6>) we've included on our page.

Headings organize our page, giving screen reader users another way to orient themselves to its contents. A screen reader user might start by reading all the level 1 (<h1>) headings in the document. They could then choose to drill down further into a section and read through all the level 2 (<h2>) headings there, then all the level 3 (<h3>) headings, and so on.

<body>

    <h1>Heading Level 1</h1> <!-- Reading Order: 1 -->

        <h2>Heading Level 2</h2> <!-- Reading Order: 2 -->

            <h3>Heading Level 3</h3> <!-- Skipped -->

        <h2>Heading Level 2</h2> <!-- Reading Order: 3 -->

            <h3>Heading Level 3</h3> <!-- Reading Order: 4 -->

            <h3>Heading Level 3</h3> <!-- Reading Order: 5 -->

            <h3>Heading Level 3</h3> <!-- Reading Order: 6 -->

</body>

We can assist with this workflow by having headings in the first place. Without them, we're handing our screen reader users a wall of text they'll have to listen to line-by-line to find what they need.

Beyond having headings, we should ensure they work together to create a meaningful hierarchy.

To do this, it's a good practice only to have one <h1> element in the document, which serves as the title for our page. That <h1> could even be the same as the <title> element in the head. Then, our <h2> elements can serve as our top-level section headings. If we need to get more granular within each section, we can use <h3> through <h6> as needed.

When laying out our hierarchy, we mustn't skip headings. <h1> should only be followed by <h2>, which should only be followed by <h3>, etc. Skipping headings (say, by moving from <h1> into an <h3>) could confuse screen reader users, who might wonder if they accidentally skipped a heading.

For the heading text itself, the same rule of thumb we can apply to page titles also applies here -- keep it unique, brief, and descriptive.

<h1>Michael Scott Autobiography</h1>

<!--Don't Do This: -->
<h2>Part 1</h2> <!-- Not unique or descriptive -->

<!--Instead, Do This: -->
<h2>My Childhood</h2> <!-- Describes topic for section -->

<!--Don't Do This: -->
<h2>My philosophy is, basically this. And this is something that I live by. And I always have. And I always will. Don’t, ever, for any reason, do anything, to anyone, for any reason, ever, no matter what, no matter where, or who you are with, or, or where you are going, or, or where you’ve been. Ever. For any reason. Whatsoever.</h2> <!-- Not brief -->

<!--Do This: -->
<h2>My Philosophy</h2> <!-- Brief summary of section topic -->
<!--Move the rest to the actual text content of the section. -->
<p>My philosophy is, basically this. And this is something that I live by. And I always have. And I always will. Don’t, ever, for any reason, do anything, to anyone, for any reason, ever, no matter what, no matter where, or who you are with, or, or where you are going, or, or where you’ve been. Ever. For any reason. Whatsoever.</p>

A common issue I've seen with heading tags is using them for styling purposes, like font sizing. Perhaps <h2> feels too big, and the size of <h3> fits better for our aesthetic. Perhaps the boldness of an <h1> heading is what we're looking for to bring attention to a quote or essential information. In either case, the answer isn't to use a different heading level. This will otherwise lead to a disjointed reading experience for our screen reader users. Instead, we should change the styling within our CSS and stick to using heading tags for page organization.

<body>

    <h1>Michael Scott Autobiography</h1> <!-- Reading Order: 1 -->

    <h2>My Childhood</h2> <!-- Skipped -->
        <p>When I discovered YouTube, 
        I didn’t work for five days.</p> <!-- Skipped -->

    <h2>My Career</h2> <!-- Skipped -->

        <p>I am Beyoncé, always.</p> <!-- Skipped -->

    <h2>My Philosophy</h2> <!-- Skipped -->

    <h1>"You miss 100% of the shots you don't take. -Wayne Gretsky" -Michael Scott</h1> <!-- Reading Order: 2 -->

    <p>My philosophy is, basically this. And this is something that I live by. And I always have. And I always will. Don’t, ever, for any reason, do anything, to anyone, for any reason, ever, no matter what, no matter where, or who you are with, or, or where you are going, or, or where you’ve been. Ever. For any reason. Whatsoever.</p> <!-- Reading Order: 3 -->

</body>

Give Context with Link Text

Screen reader users can also get a sense of a page's content using the "list all links" shortcut built into their software. This allows them to skip around the different hyperlinks embedded into the page, which we've coded using <a> tags.

This shortcut is only as powerful as the text we provide within the <a>, as that is what the screen reader announces. The most common pitfall here is using vague text for links, such as "click here," "here," "read more, "more," or "link."

<h1>Sales Team Directory - Dunder Mifflin Scranton</h1>

<ul>

    <li>Dwight Schrute | Email: <a href="mailto:dwightschrute@dundermifflin.com">Click Here</a></li>

    <li>Jim Halpert | Email: <a href="mailto:jimhalpert@dundermifflin.com">Click Here</a></li>

    <li>Andy Bernard | Email: <a href="mailto:andybernard@dundermifflin.com">Click Here</a></li>

    <li>Stanley Hudson | Email: <a href="mailto:stanleyhudson@dundermifflin.com">Click Here</a></li>

    <li>Phyllis Vance | Email: <a href="mailto:phyllisvance@dundermifflin.com">Click Here</a></li>

</ul>

The same standard we've followed for the text within our <title> and heading elements applies to <a> elements: keep them meaningful but brief. Users should understand where the link will take them without the context of the surrounding text. Here is how the same directory could be more screen reader-friendly.

<h1>Sales Team Directory - Dunder Mifflin Scranton</h1>

<ul>

    <li>Dwight Schrute | <a href="mailto:dwightschrute@dundermifflin.com">Email Dwight</a></li>

    <li>Jim Halpert | <a href="mailto:jimhalpert@dundermifflin.com">Email Jim</a></li>

    <li>Andy Bernard | <a href="mailto:andybernard@dundermifflin.com">Email Andy</a></li>

    <li>Stanley Hudson | <a href="mailto:stanleyhudson@dundermifflin.com">Email Stanley</a></li>

    <li>Phyllis Vance | <a href="mailto:phyllisvance@dundermifflin.com">Email Phyllis</a></li>

</ul>

If we find ourselves saying, "for XYZ, click here," chances are good we could revise that down to "XYZ" for our link text.

One practice to avoid is using the URL itself as the link text. Unless the link is very basic (e.g., wikipedia.org), a URL is neither brief nor meaningful when read by a screen reader. Instead, it will read like a jumble of characters.

Another practice to avoid is making a link out of an entire paragraph (say, if we wanted to reference a website we pulled a quote from). The screen reader will read that whole passage as part of the link list.

Web Accessibility Basics for Beginners

Bianca Aspin — Wed, 15 Feb 2023 05:41:05 +0000

What is web accessibility, why is it important, and why should we start learning about it now when we're just starting ourselves?

Disclaimer: This first blog post in the series will be more philosophical than the other posts in the series. I'll be providing context for the more technical lessons we'll dive into in later posts.

Why I'm Interested in Web Accessibility

First, you should know that anytime I say "beginner developer," I'm also referring to myself. I began my journey toward a new career in software development recently. I've been drawn toward this field for many years, though. So what started me down this path? Accessibility.

Before programming, I spent seven years working in a college disability resources department. I helped students work around barriers posed by course materials not designed with differing abilities in mind. Those students, in turn, taught me a great deal about what ‘accessibility’ means for users. I discovered how widespread accessibility issues are in the apps and tools many of us take for granted.

Here's a small sample of the problems my students and I encountered:

A publisher's proprietary software students had to use to read their digital textbooks (the only format available). It claimed to be "accessible" but lacked the proper structure for screen readers to navigate effectively.
Course management systems that were too cluttered and complicated. This made it difficult for someone with any issues with executive functioning to keep track of courses and assignments.
A billion-dollar company's popular statistical analysis software. Users could not adjust the font size of the minuscule numbers on the screen.

In each of these situations, inaccessible technology made life harder for students. Working around these issues created more work for them to get things done. The extra effort needed put them on unequal footing with their peers. For instance, in the last example I shared, the only workaround available for this student with low vision was using the screen magnification settings built into their laptop. This required them to learn a new way of navigating not just the program, but also their computer with the many keyboard shortcuts needed. All this on top of learning statistics (of all the difficult subjects)!

I was frustrated on behalf of my students. Technology was supposedly "the great equalizer," yet it seemed to create more issues than it resolved. Moreover, when working with the vendors, it seemed like all they could offer me were more workarounds and not actual accessibility solutions.

Why I'm Writing This Blog

With all this, I became curious to learn more about what happens “under the hood” that makes a given piece of technology ‘accessible’ (or not).

Of course, just as if I were to open up an actual car hood to see what was happening underneath, I was perplexed and overwhelmed when I took that first look. How are all these parts connected? How do they work together? Where is that leak coming from? I felt that way as an end user trying to find solutions for my students. I still feel that way now that I have some knowledge of software development, but at least now, I have more context.

I hope to provide you with a better understanding of that context by sharing my thoughts and findings in this blog. I'm learning the nuts and bolts of how this works with you.

Before we go further, let's talk more about what "accessibility" means on the web.

Accessibility in a Nutshell

To make a webpage accessible is to ensure that anyone can use it, whether or not they have a disability.

As it turns out, people with disabilities constitute much of our potential userbase. The Centers for Disease Control and Prevention estimate that around 1 in 4 adults (26%) in the United States experience a disability. The World Health Organization puts this statistic at 1 in 6 people (16%) worldwide. (See the 'CDC's Disability Impacts All of Us' infographic and the WHO's 'Disability' fact sheet for other statistics related to disability in the US and worldwide.)

Disability covers the many physical and mental conditions impacting mobility, cognition, independent living, hearing, vision, and self-care. It's a broad category, and there are a wide variety of barriers users with disabilities may encounter when accessing content on the web. Because of this, there is no concrete definition or standard that says, "my page is now accessible." Accessibility is not a one-and-done checklist item but an ongoing process. But, thanks to the World Wide Web Consortium (W3C)'s Web Accessibility Initiative, we do have several helpful guidelines—the Web Content Accessibility Guidelines (WCAG) to be precise.

The guidelines themselves are dense and technical, so you don't need to dive too deep down this rabbit hole yet as a beginner developer—for today, know they exist. (As an interim resource, MDN has a set of helpful articles unpacking various aspects of WCAG, Understanding the Web Content Accessibility Guidelines.)

However, now is the perfect time to start thinking about WCAG's four user-centered principles of accessibility, also known as POUR.

Our Goal: Design POUR Websites

To be accessible, our websites should be:

Perceivable
Operable
Understandable
Robust

Let's unpack these principles a bit.

Perceivable

Users should be able to take in our content even if they're missing one or more of their senses: sight, hearing, or touch (as of this writing, smell and taste are not used on the web—yet...).

Two examples of making content perceivable are providing captions for audio and video content and alt text or image descriptions for visual content.

Operable

Users should be able to enter inputs and interact with our content regardless of which hardware they use (keyboard, mouse, screen reader, mouth stick, etc.).

One example of making content operable is ensuring that all of a site's functionality is accessible using a keyboard alone. Another consideration would be testing that the site functions as expected in both mobile and desktop environments. We don't want to exclude users whose disability makes navigating the web easier on a handheld device such as a tablet or phone.

Understandable

Users should easily know how to interact with our site.

Some examples of making content more understandable include using as plain language as possible—particularly when giving instructions on how to interact with the site—laying out content consistently and logically, and ensuring that any interactive elements like forms are labeled clearly and work predictably.

Robust

Users should be able to interact with our content regardless of which browser, plug-ins, and assistive technology they use.

One example of how this comes up: our users may be most familiar with using their assistive technology in one browser in particular. As developers, we'll want to ensure our content is cross-browser-compatible.

For more information about the POUR principles of design, I recommend looking at the nonprofit accessibility advocacy group WebAIM's library of resources (which you may find easier to digest than the raw standards themselves), including their article Constructing a POUR Website. I'll revisit these principles as we explore more technical content in the following blogs.

Conclusion

Programming and web accessibility are both complex. Trying to make sense of either of them on their own can be intimidating. If you're reading this, you're already working through figuring out that programming one. Yet, even though that accessibility piece looks daunting, and we already feel like we have our hands full with just getting our first lines of code to work, as beginner developers we should start wrapping our heads around these concepts now. We want to get into good habits early and make sure everyone can enjoy the things we create. I've learned from experience that it's much easier to make something accessible from the start than to make it more accessible later on. More importantly, accessibility is a crucial design consideration—not a "fix."

With the tools we're learning now, the power to design amazing user experiences is at our fingertips. With that power also comes responsibility. As developers, we are responsible for ensuring that the wonderful things we create are accessible to anyone who might use them.

DEV Community: Bianca Aspin

What I've Coded This Week (Week 3—WWCode '100 Days of Code' Challenge)

Quick Links

React Native—The Case of the Missing Arrows in React Native Calendars

JavaScript—JavaScript30 Project #3: CSS Variables

A Note on the 'Input' Event

JavaScript—JavaScript30 Project #4: Array Cardio (Day 1)

Responsive Design—Kevin Powell's 'Conquering Responsive Layouts' (Week 1)

Looking Ahead

What I've Coded This Week (Week 2—WWCode '100 Days of Code' Challenge)

What I've Worked On This Week

Quick Links

JavaScript—JavaScript30 Project #2: JS and CSS Clock

JS30 Project 2: Clock Ticking - YouTube

JS30 Project 2: Visual Glitch - YouTube

Python—Adventures with Unit Testing

React Native—Patching Packages

Looking Ahead

What I've Coded This Week (Week 1—WWCode '100 Days of Code' Challenge)

What I've Worked On This Week

Quick Links

JavaScript—JavaScript30 Project #1: Drum Kit

Python

GMail Web Scraping Tool

'Days of Code' Python Challenge

Linux Command Line—OverTheWire's 'Bandit'

React Native—'Random Acts of Kindness' App

Looking Ahead

Code-Along: Implementing 'Search By Criteria' Functionality with React, Formik, and Flask-SQLAlchemy

My Current Project

The Problem I'm Trying to Solve

My Vision for the Search Function

Create 'Search' and 'Results' Components

Create the Initial Form

Configure Formik

Backend

Create API Resource and Route

Build Out Query Logic

Add Error Handling if No Matches Found

Tying the Frontend and Backend Together

An Alt-Text Primer

An Alt-Text Primer

What is Alt-Text?

What Happens if I Don't Include Alt-Text?

What Should I Include in my Alt-Text?

alt tags for decorative images should be empty

alt tags shouldn't include "image of" or "graphic of"

alt tags should be brief yet represent the content and function of the image

Additional Resources

Two Ways to Make Your Command Line Interfaces More Accessible

Introduction

The Accessibility of CLIs

Research Study

Recommendations

Let users bypass visual elements

Let users export tables to CSV

An Introduction to Screen Readers and HTML Accessibility

Screen Readers and Accessibility

Steps for Improving Screen Reader Accessibility

Include a Descriptive Page Title

Provide a Meaningful Hierarchy with Headings

Give Context with Link Text

Further Reading

Web Accessibility Basics for Beginners

Why I'm Interested in Web Accessibility

Why I'm Writing This Blog

Accessibility in a Nutshell

Our Goal: Design POUR Websites

Perceivable

Operable

Understandable

Robust

Conclusion

`alt` tags for decorative images should be empty

`alt` tags shouldn't include "image of" or "graphic of"

`alt` tags should be brief yet represent the content and function of the image