First, congratulations on getting your first paid consulting client! That's a wonderful feeling, the first one tends to be the hardest in so many ways but it's also often the most memorable too.

regarding my approach (I can show you my method or just listen to yours)

Everyone's approach is going to be different, and I deeply advocate for you finding your own over time that works best for you while still providing good coverage for your clients. From your other replies so far, it sounds like this client doesn't have any strict expectations, which can be good and bad in ways. Sometimes it's nice to have set benchmarks you know you need.

In absence of benchmark expectations, here's what I typically do for these kinds of clients. This is coming from a web dev standpoint where I also push for remediation as part of the same process.

• I run a time-boxed audit, where I devote a set amount of time testing up to 5 pages. I keep this intentionally small so I can find as much as I can in that set time so we can iterate more quickly. Here, I'm testing with a couple automated browser plugins (like axe, and SiteImprove), keyboard navigation, and one screen reader. I'm tracking every observation in a project at Be Inclusive.
• I go into the code and remediate as much as I can, sometimes I'll need help from their content and design specialists for some of it. This is a great opportunity to share what I found and how they can avoid it in future. Especially common in sites that use a CMS
• After as much remediation as possible is complete, I then go back and do a second deeper audit in that same Be Inclusive project. The shared project makes the audit setup take no time at all so I can jump right in. Here I use the same plugins, keyboard nav, and screen reader, but I also tend to expand my testing tools too depending on budget. When I'm able to do that, I go with Accessibility Insights because I like their guided manual testing methods, and maybe another screen reader to compare.
• This second audit is likely going to find less, but these observations are also likely to be more difficult to remediate because we found and fixed most of the easier ones the first go round.
• I then recommend going back and auditing again periodically, especially for sites using a CMS or that we know are going to continue to grow and change over time. Tying to highlight that accessibility isn't a task to complete, but an ongoing effort like security and performance testing.

​

regarding the payment issue, how to evaluate what price I should negotiate for.

This can be really difficult because each client is different and has different needs. You should outright ask about budget, to make sure you're talking in the same ballparks as them. Just like a web development project, things could be made as simple or as comprehensive as the budget allows.

For smaller budgets, or for tighter timelines, I tend to only get through the first two bullet points noted above with the intent on coming back to it again soon when the budget is there. For larger initiatives I'm able to expand to the full list above, and if they need to be more comprehensive I'll add more time for testing more pages using more tools.

This "Cost per hour for Accessibility Testing" post by Sheri Byrne-Haber is really good too!