• LettuceEat
• Introduction
• Related Work
• Methodology
• Disability Justice Perspective
• Learnings and Future Work
• How We Made Our App Accessible

LettuceEat

Link to our product Lettuce Eat.

Introduction

Our team has built a web application that provides people with specific dietary restrictions the ability to create a custom diet filter and find dining options at restaurants in the Seattle, WA U-District area. The application has pre-parsed dietary restrictions provided but users are able to add any other filters that will meet their dietary needs. Additionally, we have a form that users can fill out to submit data of specific restaurants not in our database. We have begun with a small number of restaurants in our database, hoping this project would serve as a foundational step toward exploring efficient ways to parse menu information from the internet and organize dietary data.

In our research, we found several first-hand accounts from individuals with food restrictions, including those who have celiac disease, that demonstrate the obstacles they encounter when searching for restaurants that cater to their dietary needs. We believe that creating technologies or providing resources, like our project, that share organized data on restaurant menus will help make the process of finding suitable dining options easier.

Related Work

HappyCow is a website for finding vegan restaurant options, which enables users to locate vegan restaurants near them and read reviews of those restaurants. There is also an app that was made by the “Celiac Disease Foundation” that allows for easier ingredient shopping and provides gluten-free recipes for people with celiac disease. Such platforms provide valuable insights into each restaurant’s offering and share additional helpful resources to support communities with specific dietary restrictions.

Our project aims to draw inspiration from these examples in supporting the community through providing well-organized restaurant data. Notably, we learned that existing resources tend to focus on particular dietary preferences, rather than considering the intersectionality among dietary needs by combining multiple options. Acknowledging the intersectionality of dietary and accessibility needs, we intend to explore this idea further by allowing users to select multiple dietary options (vegan, vegetarian, and celiac) as well as specify ingredients they prefer to avoid. This customization feature will embrace intersectionality and help users to address their specific requirements.

Methodology

• Parser that extracts menu data into a CSV file Our parser works on restaurants that have the menu along with the ingredients for each menu item on a webpage. To implement the parse, we used the Python libraries BeautifulSoup and Selenium. First, we use Selenium to parse the website into html, and print out the html. Then, we manually look in the html for the tags where the menu items and menu descriptions are stored. Next, BeautifulSoup is used to search the website for those menu items and descriptions and store the results in an array. This is used to create a csv using the pandas package. For each restaurant, we created a csv file with a column for the menu item names, a column for the corresponding menu description, and an optional column for the dietary information (like gluten free or vegan) if that information is on the website.

• Airtable that filters menu data depending on user input We utilized Airtable, a cloud-based, user-friendly interface to help us create our relational database. We did this by taking the produced comma separated value formatted menus for each restaurant and importing them to Airtable. We then contextualize the restaurant and their respective menu by adding dietary-preset tags based on the ingredient description and recipes found online. These dietary presets help curb any potential missing results that may occur by just searching ingredients by name. For example, if we were to filter out anything that contains “pork,” then bacon or prosciutto will still show up in the menu, even though it is also a pork-derived product, thus showing our users inaccurate results. We also ensured that the filters would not exclude items based on their description. For example if a restaurant had fried rice as a menu item and included “+$2 for pork, +2 for prawn, +$3 for beef,” it means that the fried rice normally does not contain “pork”, “prawn” or “beef” but it would still be filtered out for users because the description contained potentially filtered keywords when the menu dish may not inherently contain that ingredient. Additionally, to maintain accuracy, we also separated two types of the same item. For example, if there is a chicken samosa and a vegetable samosa, we separated them to be different menu entries so that the samosa dish would not automatically be filtered out if someone was looking for a vegan/vegetarian alternative because of the “chicken” included in the menu description. By doing this, we are explicit about what items contain what ingredients, making the user experience guess-free. Additionally, we are including Google Maps navigation to each restaurant, to ensure user ease if they choose a restaurant based on a menu item that they find satisfying as a result of our website.

• Testing the app as someone with a dietary restriction As someone who cannot eat pork, eats Halal for certain periods of time, is mainly pescatarian, and cannot consume dairy at times because of medications, throughout the year for religious reasons, our group member Anusha tested out the app to see how the results would show up based on her various dietary needs. She entered the following restrictions into our filtering system: “dietary presets HAS NONE OF pork” “dietary presets HAS ANY OF dairy-free, seafood, shellfish “ingredients does not contain chicken” “ingredients does not contain beef” She looked through the resulting menu items presented to her by the database and found that the results were satisfactory and did not include any errors or potential ingredients that would violate her dietary restrictions. She found the filtering system easy to navigate and more efficient than going to the physical restaurant and skimming through the menu in a rush.

Disability Justice Perspective

Intersectionality

Intersectionality is the idea that people have many different identities that impact them in many ways. Our project will address this principle by supporting a plethora of different dietary restrictions that people could have on top of their disability dietary restrictions. Initially, we just focused on have broad filters such as for vegan, vegetarian, and gluten-free. However, this design excludes people who have more niche food restrictions. For example, people with certain chronic illnesses, such as IBS (irritable bowel syndrome), may not eat a unique set of food items. Or someone might be allergic to a single food item such as carrots. Thus, in our revised design, we include a build-your-own filter that allow people to enter in the specific food items that they can’t eat. This supports the intersectionality principle by allowing people with a wide variety of food restrictions to still use the website.

Collective Access

Collective Access is the idea that access needs are shared, encouraged, and supported by the community. It is everyone’s responsibility to support others’ needs when they are communicated. Our project addresses this principle by including a feature where individuals can request for new restaurants to be added to our database. Our website also includes a feature where people can report accessibility concerns about the website. Listening to the users of the website is critical to centering collective access in our project so that we can address any access needs as necessary.

Learnings and Future Work

There are several avenues that future work that we considered when initially designing our project. First, we would like to incorporate Yelp reviews to allow our website to also display accessibility reviews for the restaurant. This would include searching for reviews that indicate whether the place is wheelchair accessible inside and outside the establishment and whether the menu is accessible. A feature could also be included to allow people to filter restaurants on accessible features of the restaurant.

Additionally, currently, our website only includes about 10 restaurants in the U-District. However, this is not a comprehensive list, and it would be great to include more restaurants in our website, in and outside the U-District. One step for this is to fully automate the process for parsing menus. Currently, our workflow includes a manual step for finding the menu html tags, so fully automating this would allow us to quickly process more restaurants.

Lastly, our filtering is completed through the application Airtable. It takes in a CSV file and then a user is able to filter for their dietary needs. Due to the lack of consistency and information provided by restaurant menus, manual verification was done to ensure accuracy. For future additions, we could create a program that is able to accurately verify the CSV files created when parsing the menus. For example, if there is a synonym of an ingredient or an ingredient not explicitly mentioned in the menu description, our algorithm can be improved so those would still be filtered correctly.

How We Made Our App Accessible

Our current version of the project utilizes existing tools such as Airtable and Google Forms to provide a demonstration of our ideas. Since we built a website that contains all the features, we placed an emphasis on enhancing website accessibility. To achieve this, we used the automated web accessibility evaluation tool, WAVE, as a starting point. During our evaluation, we identified instances where some pages didn’t have aria landmarks. For instance, our <div> tag functioning as a navigation bar on each page failed to clearly indicate its primary purpose. In response, we added role and aria-label attributes to specify that the section was for navigation. Similarly, we tried to make our form for adding restaurants accessible by incorporating for and id attributes to <label> and <input> tags within <form> to establish clear relationships. We also added aria-description attributes to <input> tags to provide descriptions of their use.

We also manually ran a color contrast checker to ensure compliance with accessibility guidelines. Instances where text and background colors didn’t meet the guidelines were addressed by replacing the original colors to meet the required contrast ratio. In addition, we added alternative texts to images, like our logo. Lastly, we used screen readers to test accessibility manually. This involved evaluating all our pages to make sure the screen reader could recognize and interact with each element properly. For example, we tried filling out the form on the Add Restaurant page to test the Add Restaurant page’s accessibility.