This is the expected behaviour - you run into a deadlock.
But most importantly, you're neglecting the fact that triggers fire per statement, not per row, so the ootcome of this statement:
select @RecId = i.[RecId], @AccessFlag = i.[AccessFlag] from INSERTED as i JOIN DELETED as d ON i.RecId = d.RecId
...is completely unpredictable.
Normally, one would handle situations like this in the stored procedure used to write to table A; namely, decide up front whether (and how) the data must be changed in table B.
If, however, for some reason you think you must be using triggers, then use the logic in the first trigger to decide whether the data should be modified in table B, rather than letting that decision fall on a trigger on table B. After all, it is table A that holds the data necessary for this decision, doesn't it?
The definition of the trigger on table A should read somewhere along these lines:
update
set
...
,
from inserted
where
and
ML
---
Matija Lah, SQL Server MVP
http://milambda.blogspot.com