DEV Community: ljg2gb

An Intro to Web Accessibility for Developers

ljg2gb — Thu, 03 Sep 2020 20:59:31 +0000

The Pandemic has changed so much about how we all live our lives. In one one way or another, we’ve all had to adapt to this “new normal”. In reflecting on these adjustments, a major theme for me has been internet access and how we can help expand it.

Living through this Pandemic, we rely on internet services to go to work, go to school, catch up with loved ones, do our shopping, and even go to our doctors’ appointments. Unlike ever before, people with disabilities, people with technical challenges, and people from different cultural/linguistic backgrounds are convening in the digital space, and are relying on web-based services and platforms.

As developers, we have a responsibility, along with designers, to create and optimize interfaces to be inclusive and accessible to everyone.

In learning more about web accessibility and how to implement it, I’ve gone down a bit of a rabbit hole. While I am merely scratching the surface, I decided to put together a list of quick wins that fellow developers can implement in an afternoon, as well as some resources that I found helpful.
Please know that there are plenty of experts on this topic, and whole courses on web accessibility. I don’t want to replace these voices and would highly recommend that you go check them out if you are interested in the subject. If you’re looking for a quick way to make your project more accessible, I hope you find that this article is a good place to start.

Implementing Quick Wins for Accessibility

Optimize your Website for Screen Readers

Screen readers allow people who are blind or visually impaired to navigate the web. They work by parsing the HTML of a webpage and using text-to-speech technologies. Unlike navigating a page by sight, where users can scan to find the content they are looking for easily, screen readers read linearly. This should be considered when designing a webpage. You can try out a screen reader on your site with NVDA for Windows or VoiceOver for Mac.

Set the document language: the lang attribute on the tag tells a screen reader what language to read the content in. Here, WebAIM gives a great example of what it sounds like if the defaulted language doesn’t match the language of the content.
Include alt-text: Including alt-text to images, videos, graphs, and other media allow people using screen readers full-access to content.
Check for empty links and buttons: Links that don’t contain text mean there’s no context as to what the link goes to, making it very difficult to navigate with a screen reader.
Use semantically correct input labels on forms: This is another common context problem. For example, having a
tag that says ‘first name’ above an input field my be clear to those visibly navigating a page but difficult for those using screen readers.

<form action="/action_page.js">
    <label for="first-name">First Name</label>
    <input name="first-name">
    <input type="submit" value="Submit">
</form>

Style Thoughtfully

Many people who are visually impaired still access the web visually. Colorblindness, for example, affects 300 million people worldwide. Epileptic users should also be considered when styling a webpage.

Check font-size: A small font can be difficult for some users to read. The WCAG guidelines recommend that no text is smaller than 9px.
Check contrast: Low contrast makes it difficult to impossible to see content for some. As a good rule of thumb design with high contrast between background and text colors. You can use this checker to see if your site’s contrast meets the guidelines. It’s also important that the meaning of an element isn’t conveyed by color alone.
Watch out for flashing colors: Gif’s videos, animations, etc. can be distracting for many people and dangerous for people with epilepsy. Multimedia that flashes at a rate of 3+ per second should be removed and looping videos should have clear controls to be able to pause. ###Allow for Keyboard Navigation Those with mobility issues may be navigating a site via a keyboard instead of using a mouse or trackpad.
Set keystrokes for click events: If you are using VSCode and have ESLint installed, you might already know about this one as it will give you a warning in the console. Luckily for developers, many interactive HTML elements like buttons and links are written with default keystrokes. However, events like onClick or hover should be accompanied by a keystroke event like onKeyDown. Here’s an example from one of my own projects.

Some Great Resources to Check Out

The A11y Project | a one-stop-shop for lots of accessibility information
A11y.coffee | digestible information for developers to learn over a cup of coffee.
Follow @cariefisher on Twitter
MDN Accessibility + ARIA pages
Accessibility evaluations tools like WAVE and tota11y

I hope you enjoyed this article. If you have any comments or suggestions, please email me at lydia.gregory.dev@gmail.com. I’d love to hear your feedback :)

Making a Site Responsive

ljg2gb — Thu, 27 Aug 2020 15:38:46 +0000

While it’s easier to design and style for various screen sizes from the beginning, sometimes we realize the need to add flexibility to our projects after we've begun. If you are retroactively adding responsiveness to an existing app, you've come to the right place.

Some background:

Learning to code in a Bootcamp program has lots of advantages. A project-focused program was great for me to solidify what I was learning. I built databases, CRUD backends, Jamstack applications, and modern web frameworks in four-day-long project sprints, and presented these projects to my classmates at the end of the week.

As a former graphic designer, I always made time to plan out and implement basic wireframes, colors, and typography in my projects. But I never got the time to learn or implement responsive design in any of my projects during the Bootcamp, which meant that after graduating I was left with four projects that I was proud of, but had no responsiveness.

Since I still hoped to deploy some of them, learning responsive web design and adding it to already existing projects was something that I wanted to do after graduating. After all, the majority of sites get more traffic from mobile devices than they do from a desktop.

When Adding Responsiveness...

1. Find What Breaks

Take some time fiddling with the size of your browser window and make a list of components that need the most work. You can also use your chrome developer tools to snap the browser to key breakpoints including tablet and mobile. Note that absolutely positioned items are very hard to work with and should be used sparingly.

2. Use a Sass or SCSS file instead of CSS

Using variables and mixins will make your stylesheet much more organized and readable. Variables also let you easily make one edit that will update your entire stylesheet.

3. Convert CSS Units from absolute to relative

Replace any absolute length units (px, pt, pc, in) to relative length units (em, vh, vw, %). This will automatically make your application much more flexible.

4. Use Media Queries

Start fixing the most glaring scaling issues first, and work your way down to the details. Set your breakpoints with Sass variables and then use a media query such as @media (max-width: 600px) or @media (max-width: $phone).

5. Flexed items

Items that are flexed in the desktop version rarely have the horizontal space on mobile. One media query that I found myself writing often was:

.text-container
     display: flex
     @media (max-width: 600px)
          flex-direction: column

// also written like:
.text-container
     @media (min-width: 600px)
          display: flex

6. Images

Images can be finicky when scaling down the screen size. By putting your image inside a div, you can fit the image to the div, which is easier to manipulate. Here are two ways to fit the image:

.image-container
     .image
          object-fit: contain
//or
.image-container
     .image
          max-width: 100%

Thanks for reading!

If you have any comments or suggestions, please feel free to email me at lydia.gregory.dev@gmail.com.

A First-Impression of Mobile Development

ljg2gb — Mon, 06 Jul 2020 03:59:59 +0000

As a web dev newbie trying out Mobile Development for the first time, I'm learning over and over again the importance of developing with User Experience as a top priority. As Frank Chimero puts it, "People ignore design that ignores people."

For my very first mobile project, I decided to build a photo application in React Native that borrowed some of the interactivity of a Polaroid camera (like shaking your phone to develop your photo). In embarking on the project, I figured the most difficult challenge was going to be technical; learning the new tech. What I didn't realize was how much thought and preparation I'd be putting into developing an app with satisfactory user experience, let alone a good one.

As I've done many times already in my short time as a developer, I've stumbled upon a rabbit hole. This one in particular, even though I don't have the time to go down it now, I have every intention of coming back to later.

In web development, the browser handles a lot of the user's interaction with a site by default. Sites live in the browser and the browser has preset rules, which aren't broken often. (Think of the little jolt of surprise you get when you go to scroll down and a site's content starts moving to the right instead.)

In mobile, it's free for all. Users can click anywhere, swipe anywhere, tilt, shake, move locations, etc. The developers (along with designers of course) are in charge of setting the rules. This means that when I create a component in my React Native project, I'm not only thinking about its state, props, style, and functionality. In mobile development, I'm also asking questions about how the user interacts with that component and how the component changes in response.

Questions like, "If a user swipes in x direction in x part of the screen, for x many pixels change will my app render to the right thing?". "What kind of feedback should I give the user to let them know that they are physically interacting with the app correctly?". "What conventions exist in mobile development and how can I implement them in my app?".

In the browser, many conventional actions are default actions. In mobile development, at least at the moment, that doesn't seem to be the case. Like my earlier example, convention lets the user scroll down and expect the page to move down. The browser's default gives the developer this convention for free.

Whether I find myself working in web or mobile development, the experience of having developed in both has been eye-opening. Specifically, the unavoidable intentionality you need when developing a good user experience for mobile is a practiced skill of mobile developers and a translatable skill to Web.

Jumping headfirst into my first mobile project only two weeks ago, I know I have so much still to learn. Here are some of my takeaways so far:

1) Design beyond the default.
2) Consider convention.
3)Provide strong user feedback even on the web.

Deploying a Ruby on Rails API to Heroku

ljg2gb — Tue, 30 Jun 2020 00:40:02 +0000

First Time Users

Note: These are tailored instructions for deploying a Ruby on Rails API to Heroku for the first time. If you already have a Heroku account scroll to the Returning Users section :)

Creating a Heroku account

1) This part is self-explanatory. Here's the link: https://signup.heroku.com/

2) You'll be creating a new app and adding your app's name and region.

Setting up Heroku

1) Install Heroku CLI. On a Mac, if you have homebrew, run brew tap heroku/brew && brew install heroku in the terminal, otherwise check out the documentation.

2) In the root directory of your backend, run heroku login and login as prompted.

3) Also in the root directory of your backend Rails application, if it's already a git repository, run heroku git:remote -a <app_name>. The app name must be the same as the name you used on Heroku.

Changing your database from its default, SQLite3 to PostreSQL

Note: If you've yet to create your Rails backend, you can initialize it with a PostgreSQL database using --database=postgresql or -d=postgresql e.g. rails new <app_name> --api -d=postgresql and skip these next steps.

Another note: If you have information in your database that should not be deleted, MIGRATE entries before continuing. I found an article that looks helpful here(although I haven't needed to do this so take the recommendation with a grain of salt!).

1) Go to Rails Gemfile. Edit lines 8 and 9 from SQLite3 to # Use postgresql as the database for Active Record gem 'pg'

2) In config/database.yml, delete all commented-out code having to do with Sqlite3 (Heroku won’t like it). Change the default adapter to postgresql, and the development database, test database, and production database to app_name_development, app_name_test, and app_name_production respectively.

3) Delete Gemfile.lock (rm Gemfile.lock). Then run bundle install. This will recreate your Gemfile AND delete your old SQLite3 database(s).

4) Run rails db:create and to create your new development and test databases.

5) Run rails db:migrate and heroku run rails db:migrate to create your tables locally and on Heroku. Check here to make sure everything looks good before moving on.

6) If you have seeds, at this point you can run rails db:seed and heroku run rails db:seed.

6) Add and commit these changes to git. If you haven't synced Heroku with your Github, run git push heroku master. Note: this command won't run unless you installed Heroku as listed in the steps above.

Syncing Heroku w/ Github

1) If you have a GitHub repo that you'd like to link to Heroku, it's super easy.

2)In your Heroku dashboard, under the Deployment Method section, you'll see the GitHub logo w/ a button "Connect to GitHub". You'll follow the prompts, sign in to GitHub, and be all set. Now, when you push new code up to GitHub, it will update your Heroku app as well.

Note: Your local database and your Heroku database are not the same. In order to make changes to the Heroku database. you have to preface your rails db: commands with heroku run. Ex. heroku run rails db:rollback

Checkout your fresh API, deployed on the web!

Use the "Open App" button in your dashboard's top right corner.

Note: Make sure you've specified a route. If you don't have a "/" homepage GET route, https://app-name.herokuapp.com gives a message that the page can't be found. https://app-name.herokuapp.com/users for example will be what you want.

Returning Users

1) Log back into Heroku and create a new app by adding your app's name and region.

2) In your backend's root directory, run heroku login and login as prompted.

3) If the repo is a git repository, run heroku git:remote -a <app_name>. The app name must be the same as the name you used on Heroku.

4) Change your database from its default, SQLite3 to PostreSQL
Note: If you've yet to create your Rails backend, you can initialize it with a PostgreSQL database using --database=postgresql or -d=postgresql e.g. rails new <app_name> --api -d=postgresql and skip these next steps.

First, go to Rails Gemfile. Edit lines 8 and 9 from SQLite3 to # Use postgresql as the database for Active Record gem 'pg'

Next, in config/database.yml, delete all commented-out code having to do with Sqlite3 (Heroku won’t like it). Change the default adapter to postgresql, and the development database, test database, and production database to app_name_development, app_name_test, and app_name_production respectively.

Delete Gemfile.lock (rm Gemfile.lock). Then run bundle install. This will recreate your Gemfile AND delete your old SQLite3 database(s).

Then run rails db:create and to create your new development and test databases. Run rails db:migrate and heroku run rails db:migrate to create your tables locally and on Heroku. Check here to make sure everything looks good before moving on.
If you have seeds, at this point you can run rails db:seed and heroku run rails db:seed.

Lastly, add and commit these changes to git. If you haven't synced Heroku with your Github, run git push heroku master. Note: this command won't run unless you installed Heroku as listed in the steps above.

5) Sync Heroku w/ Github

If you have a GitHub repo that you'd like to link to Heroku, it's super easy. In your Heroku dashboard, under the Deployment Method section, you'll see the GitHub logo w/ a button "Connect to GitHub". Follow the prompts, sign in to GitHub, and you're all set! When you push new code up to GitHub, it will update your Heroku app as well.

Note: Remember that your local database and your Heroku database are not the same. To make changes to the Heroku database, preface your rails db: commands with heroku run. Ex. heroku run rails db:rollback

Debugging Tip

heroku logs --tail will open up a server that logs requests to your Heroku backend. You can even use heroku run rails c to check User.all, etc.

Happy coding! :)

Creating a dynamic selection list with TTY-Prompt

ljg2gb — Mon, 29 Jun 2020 14:17:07 +0000

When writing a CLI application there are some Ruby gems out there that make a big difference. TTY-prompt is without a doubt one of the most popular CLI gems out there - and for good reason. TTY-prompt is extremely helpful for reducing user error which makes your code harder to break since the user is no longer typing directly into the command line to make a selection. And, I think, improves the user experience which is important even in a small-scale application like this.

Basically, the TTY-prompt gem works by reformatting the output to let the user scroll through a list of options and make a selection. Here is a classic example of the TTY-prompt in action:

However, if your app is like mine you’ll need these lists to be dynamic. If your seed data changes, or if the selection list is determined by user input, you’ll code that’s more flexible than the examples given to you in the TTY-prompt documentation, that looks a lot like the main-menu example above.

Creating a dynamic list with TTY-prompt:

My partner and I managed it by splitting it up into three methods:

Create a dynamic method that returns the selections you want to display like “list_farm_names.”
Create a method that displays the selections using TTY-prompt like “print_farm_name_list.”
Create a method that returns the selected information like “farm_selection(selection).” This will look different depending on what data you are returning and how your schema is set up. In our example, we wanted to return the farm’s website URL if one existed, a list of available products at that farm, and the quantity.