From a perspective of the theory and practice of programming languages, language elements have semantics. Naming conventions don't. And semantics has nothing to do with 'fidelity' to anything, except perhaps that if an implementation is correct it is sometimes called "faithful to the semantics."
Beyond that it's hard to generalize because there are so many different styles of semantics.
- Christopher Strachey was the one who really pushed the idea that normally a phrase (think declaration, definition, statement, or expression) is composed from smaller subphrases, and that the meaning (semantics) of the larger phrase should be a function of the meaning of the constituent subphrases. In this style, every syntactically well-formed subphrase has a semantics. It sounds like this is what you are looking for.
There are other styles of semantics, called "operational semantics", where given a program, the semantics tells you how that program will be executed on an abstract machine (or in another variant, the semantics says not how the program will be executed but only what the result will be).
There is "axiomatic semantics" which is roughly about what facts you can prove about individiual programs. The axiomatic semantics is a collection of valid proof techniques. It's up to the implementation to ensure that all provable claims are true.
There is also "static semantics", by which is meant broadly any requirements imposed at compile time for the program to be considered "good" or "well formed". Stuff like "variables have to be defined before they are used" is static semantics. But mostly when people say static semantics they mean type checking.
Finally, it is possible to speak of the "semantics" of an abstract data type, a class, or an interface, among others. This usage are a good deal looser, but they boil down to a specification of what behaviors are permissible. I advise you to avoid the word "semantics" in this context and to use the word "contract" or "specification" instead. It will avoid confusing things.
Commentary: it's not always helpful to try to boil down a complex subject to one or two sentences. And when it comes to programming languages, don't look for good information on Wikipedia. The Wikipedians mean well, but too often they are complex, confusing, or just plain wrong.