In general, when Access sees a relationship between two fields, it can tell by the uniqueness criteria on the fields whether the relationship should be one//one or one//many. If the relationship is between the prime keys of both tables, then you always get one//one because prime keys must be unique. (You can't build a many//many relationship directly, though you could do so through something called a JUNCTION TABLE. But that isn't your question so I'll ignore that option.)
Here's the bottom line: If the ID field is unique in both tables, that is where your problem lies. I can't confirm this because your ERD won't show us the uniqueness, only that something is a key.
I'm going to digress to explain the fine point of design that governs this choice of keys.
The general rule is, no matter whether the field is a prime key in any OTHER table, if it is going to be part of a one//many relationship, it must be treated as a foreign key on the many-side table. For which it can still be indexed but with duplicates allowed.
The other side of that same rule is that generally, a key is prime/unique in one and only one table. It is foreign or else is part of a compound key in all other tables that reference it. The table in which the key is prime is the table that describes the thing to which that key refers. E.g. if you have a stakeholder ID, it would be unique only in the table of stakeholders, nowhere else.
Why? Because with very few exceptions, anywhere else in the database, it cannot be the prime key by itself.
Why can't it be prime by itself elsewhere? Well, this is a fine point of design and some folks might not fully agree with this because it verges in to the ART (not science) of database design.
If the records in two tables depend completely and only on the same field, you have or imply a one//one relationship between those tables - which actually is rare. Not unheard of, but rare. It ALSO means the tables are individually incomplete. Bear with me on this one.
The immediate question is why you didn't merge the two tables by adding fields or records to accomodate the extra data. This is because of key selection rules about uniqueness and completeness.
In a properly designed and fully normalized database, the records of any one table depend uniquely and completely on the prime key. If you have TWO tables that meet this criterion for the same exact key and the same exact VALUES for that key, then the two tables are each PARTIAL descriptors of the thing uniquely and completely described by that single key. Which says that the tables taken individually are incomplete.
Now, if one of the two tables using the same prime key is SPARSE - i.e. sometimes blank, or if the data in one of the tables doesn't get used very often, these are excuses for the layout being split into two tables with the same exact key. These are the rare cases. (In the sparse case, this is still a problem since in that case the key in the sparse table should be treated as one//many anyway - because otherwise JOINs won't work right.)
