Skip to the content.


Link to our product Lettuce Eat.


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.


Disability Justice Perspective


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.