You used the wrong entity name. A hanging itemframe is not called ItemFrame but item_frame.

So, the following command would work:

/testfor @e[type=item_frame,r=10] {Item:{id:minecraft:writable_book,tag:{display:{Name:"Keys"}}}}

Please note: this command checks the name given to an item. You are essentially looking for a writable book that has been renamed using an anvil. If your goal is however to check for a closed book with a title you should use the following command:

/testfor @e[type=item_frame,r=10] {Item:{id:minecraft:written_book,tag:[{title:Keys}][2]}}

No, unfortunately not.

However, there is a way to detect players looking at a specific block. I'll have to warn you, its possibilities are limited.

So, lets look at whats available and could be helpful:

• @p || nearest player
• @r || random player
• @a || all players
• @e || all entities

The only two target selectors we could possibly use for this contraption are the @p or @a selector. We don't have to use the nearest player to the command block, and therefore still can place the command blocks anywhere. Why? Target selector arguments

As there are many many target selector arguments, I'll directly show which ones can help to answer this question. We need to specify a number of arguments that all must be true for a player to be found.

Note! The next part only focuses at finding players looking at specific coordinates! Note also, that the solution may not be 100% accurate!

There just is no target selector argument that lets us filter by the target block. Using x, y, z, r, rm, rx, rxm, ry, rym, dx, dy, dz as arguments, we are able to hardcode all the possible positions and and rotation pairs.
How much work is this? Assuming the block is in/on an open space, there are 16, 25, 36 or more pairs to find and put into command blocks. When using this in an adventure map, it depends on the map and of course the surrounding area. Generally speaking, there should be one rotation-location pair per block the player should be able to stand on and still can see the block (thus we're only using integer locations).

If you want to make this a lot easier for you, have a designated spot for the player to stand and mark it somehow.

Finally, let's build the command: The dx, dy, dz argument specify volume. That means for each coordinate (x=23,y=64,z=-15) which is specified with integers, using dx=1,dy=1,dz=1, we can build a simple 1m³ box which occupies exactly the same space as a block placed at the coordinates x=23,y=65,z=-15 (65!). This is the box the player has to stand in. The radius (r, rm) arguments can now be omitted. The last thing to specify is the rotation. When standing at a certain coordinate, you want to have a sort of box, and therefore need to read 4 values (rx, rxm, ry, rym) from the debug menu (F3). In the Facing line in the debug menu, you may find something like 154.3, -56.2.

The first value is the horizontal rotation (ry).

Horizontal rotation values vary from -180.0 (facing due north), to -90.0 (facing due east), to 0.0 (facing due south), to 90.0 (facing due west), to 179.9 (just west of due north) before wrapping back to -180.0 (thus horizontal rotation values increase with rotation to the right, or clockwise viewed from above).

The second value is the vertical rotation (rx).

Vertical rotation values vary from -90.0 facing straight up to 90.0 facing straight down (thus vertical rotation values increase with rotation downwards).

Now you need to point your cursor at each of the 4 different corners or sides of the target block and note the respective value. When you finally insert that into the command, make sure you assign the correct values to the minimum / maximum arguments. An easy way is reading the horizontal rotation clockwise and the vertical downwards. The first value you note will always be the minimum value, although the numbers themselves probably won't make sense (the minimum can be greater than the maximum!). To understand that, you need a bit of 3D-imagination. Imagine a bubble with radius 1 centered in the middle of your head. The bubble as a whole moves as you move, but it doesn't rotate; one side is always facing north. On the bubble there are 2 axes also known as Pitch and Yaw - or rotation. The same way 2 axes do in math class, they create a 2D coordinate system - except this one is printed on a bubble. When you were to mark the four points in the coordinate system, you could draw a square (or at least a polynomial that looks like a square in some respects). This is the square the player's cursor has to be inside of to be detected.

As I've just mentioned, it is going to be hard / impossible to have a real square or to have a polynomial which covers the block exactly. Most likely, the area which will be detected is going to be a bit larger than the area where the player is actually looking at the block.
By sharing the x or z coordinate between the block the player is supposed to look at and the block the player is supposed to stand on, accuracy increases to 100%.

This answer is already long enough, so here is looking at any block of type X:

Thinking about this, it came into my mind that one could "invert" the described method to not have specific coordinates and an area around these where the player has to stand inside of, but to use the /execute command and relative coordinates to create an area that moves along with the player. When assuming the target blocks are always on the floor, it is possible to apply the rotation to every location. This would require the floor to always have the same level near such blocks of type X. When trying to extend this into three dimensions, the following problem occurs: Multiple layers can not be supported, because this would mean players are able to look at more than just one of the supported blocks in a radius of r blocks around themselves. That would result in two or more command blocks activating and possibly executing other command blocks very often although they're intended to be only executed once.

Note! Each and every /testfor or /execute command described in the last paragraph requires another /testforblock(s) to be executed afterwards to check for block type X.

To put in a nutshell, detecting players looking at any block of type X is easily done by detecting players standing on top of the block and looking straight down. Supporting any other possible player-block-arrangements is a lot harder.

I hope I was able to present my thoughts more or less clearly, just ask if anything doesn't make sense to you!