Input Mask Code Not Displaying-Access

Can you share a sample db with that table and no data?

Also, days entry is done in forms, NEVER directly in tables or queries.

My textbook (ACCESS - ESSENTIAL FUNCTIONS with Microsoft 365: OPTIMUM SERIES) specifically instructed to from the table, hence why I'm confused. Here's a screenshot of the section for reference.

The fact that you can apply an input mask in a table's datasheet does not mean that you should.  Take the advice of Daniel, a highly experienced and greatly respected professional.  You should only enter or edit data in a form, so that's the place to apply the input mask.  It's best to leave a table's datasheet in its raw state, so that you can see the actual values in the columns, not the formatted, or even worse 'looked up' values.

In form design view select the control bound to the phone number field.  Open the form's properties sheet if it's not already open and, on the data tab, select the input mask property.  Click on the build button, i.e. that on the right with 3 dots.  That will open the input mask wizard.  The phone number mask will be at the top of the list, so select it.

Just follow the steps in the wizard.  When you get to the end, I'd recommend that you elect to store the number without the mask symbols.  When you close the wizard's dialogue you should see the mask symbols in the properties sheet.

I just want to add a voice in support of the solid, professional advice Daniel and Ken have provided. They are two of the most reliable, experienced and widely respected experts on Access development participating here. There are, of course, others here who are in that same category.

Over the years, Microsoft has often injected interface design elements, such as Lookup Fields and Input Masks, into data elements, despite the fact that doing so muddies the waters unnecessarily.

Their justification for doing so, is that it "makes it easier" for beginners to get started. However, beginners are the very people who don't yet understand the negative implications of forcing interface design features into the wrong objects, i.e. tables. Hence, they can get off on the wrong foot and end up in difficulties such as the problem expressed in this discussion.